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In  the  early  1980's  the  Air  Force  began  an  extensive  program  in  Cockpit  Automation 
Technology  (CAT)  aimed  at  improving  crew  station  design  through  improvement  of  the 
engineering  design  process.  This  program  focused  on  incorporating  computer  aids  into  the 
design  process,  particularly  analysis  tools  which  could  help  determine  how  automation 
technology  should  be  used  to  alleviate  pilot  task  and  attention  overload.  During  Phase  1  the 
CAT  concept  was  studied  and  refined.  In  Phase  2  the  CAT  design  process  was  developed 
and  applied,  and  development  of  a  cockpit  automation  design  support  system  was 
undertaken. 

Phases  2  and  3  were  begun  in  the  late  1980's,  the  major  role  being  played  by  Boeing 
Advanced  Systems  in  Seattle.  Objectives  were  to  further  develop  the  CAT  design  process 
methodology  and  support  systems,  and  to  include  mission,  cockpit,  task  and  function 
allocation  analyses  software  tools  as  one  segment.  As  development  progressed  at  Boeing, 
Air  Force  Advanced  Development  Program  Office  (ADPO)  personnel  saw  the  advantages 
of  having  a  "close-by"  beta  site  where  the  tools  could  be  tested,  evaluated,  and  maintained 
by  personnel  who  were  connected  directly  to  neither  the  Air  Force  nor  to  Boeing. 
Furthermore,  the  site  could  develop  as  the  tools  themselves  developed,  so  that  after  final 
acceptance  of  this  CAT  segment,  the  site  and  its  technical  personnel,  now  knowledgeable  in 
tiie  use  of  the  tools  and  their  applications,  could  become  the  vehicle  for  transferring  this 
technology  to  the  crew  station  design  community. 

The  Crew  System  Ergonomics  Information  Analysis  Center  (CSERIAC),  managed  by  the 
University  of  Dayton  Research  Institute  (UDRI)  and  located  at  the  Human  Engineering 
Division  of  the  Armstrong  Aerospace  Medical  Research  Laboratory  (AAMRL/HE)  at 
Wright-Patterson  Air  Force  Base,  undertook  this  role.  Defense  Logistics  Agency  Contract 
Number  DLA9()0-88-D-0393,  Task  01,  was  issued  on  6  July  1989  by  the  Defense 
Electronics  Supply  Center  (DESC)  to  the  University  of  Dayton  for  a  contract  period  of  18 
months.  [5. 1 .]  The  first  delivery  (from  Boeing)  of  CAT  hardware  and  software  occurred 
five  months  later,  in  December.  During  the  next  eight  months,  it  became  evident  that,  due 
to  circumstances  largely  beyond  the  control  of  both  the  Government  and  the  University, 
satisfactory  completion  of  all  task  items  by  the  contract  end  date  was  either  not  possible  or 
not  desirable,  and  an  amendment  to  the  task  descriptions  was  requested  and  granted.  This 
final  report  summarizes  the  technical  work  done  under  the  amended  contract. 


1.1. 


General  Task  Description 


CSERIACs  broad  responsibilities  were  (1)  to  host,  operate  and  maintain  the  Boeing- 
developed  CAT  tools  and  their  related  commercial  products  and  databases;  (2)  to  evaluate 
and  critique  these  software  tools;  and  (3)  to  transfer  this  technology  (the  use  of  these  tools) 
to  the  design  community--  by  giving  demonstrations  of  its  capabilities,  running  training 
workshops,  and  providing  independent  analyses  services.  [5.1.] 

1.2.  Boeing-Delivered  Resources 

The  hardware  component  of  Boeing's  Early  Designer’s  Computer-Aided  Design  System 
(DCADS)  Delivery  in  October  1989  that  was  received  by  CSERIAC  consists  basically  of 
one  DEC  super-mini  (VAX  8250),  one  Silicon-Graphics  workstation  (IRIS  4D/50G),  one 
DEC  graphics  workstation  (VAXstation  II/GPX),  and  standard  peripherals  for  those 
systems  (disk  and  tape  drives,  controllers,  terminals,  networking  hardware,  etc.).  A 
complete  listing  of  these  items  appears  in  the  hardware  inventory  prepared  by  CSERIAC  in 
March  1990.  [5.2.]  In  accordance  with  AAMRL  practice,  the  component  systems  were 
given  node  names-  the  VAX  8250  is  known  as  MERLIN,  the  IRIS  4D/50G  as 
CATBIRD,  and  the  VAXstation  II/GPX  is  called  WREN. 

The  software,  some  of  which  was  delivered  the  following  December,  consisted  of  the  V  AX 
VMS  operating  system  and  the  standard  software  utilities,  languages,  editor,  etc.,  and  the 
IRIX  operating  system  (UNIX  for  the  IRIS  workstation) ;  graphics  software;  networking 
software;  word-processing  software;  the  commercial  products  integral  to  CAT  (the  CAD 
package  I-DEAS,  the  DBMS  package  Ingres,  and  the  specialized  mission  decomposition 
program  MDTOOL);  and  the  CAT  tools  developed  by  Boeing.  A  complete  listing  of  these 
items  appears  in  the  software  inventory  prepared  in  February  1990.  [5.2.] 

The  manuals  provided  by  the  commercial  vendors  (DEC,  Silicon  Graphics,  Ingres,  and 
SDRC  for  I-DEAS)  were  the  only  documentation  accompanying  the  hardware  and 
software,  since  MDTOOL  (by  Merit  Technology)  and  the  Boeing  tools  were  still  under 
development.  A  listing  of  these  items,  likewise,  is  given  in  the  documentation  inventory 
prepared  in  February  1990.  [5.2.] 
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In  addition  to  delivering  the  hardware,  software  and  documentation  that  comprised  their 
Early  DCADS  Delivery,  Boeing  technical  personnel  helped  install  the  hardware  and 
software  systems  and  provided  a  training  course  from  4-15  December  1989.  (5.3.] 

1.3.  AF-$upplied  Resources 

Some  hardware,  software  and  accompanying  documentation  came  to  CSERIAC  directly 
from  the  Government-  for  example,  the  Tektronix  printer  and  rasterizer,  Wollongong 
network  software,  various  cables,  etc.  The  inventories  listed  above  include  these  items 
although  their  origin  is  not  specified.  [5.2.] 

The  Government  also  supplied  an  office  (Room  4  in  Building  196  at  WPAFB  Area  B)  that 
was  to  be  used  as  a  computer  room/demonstration  room/training  center/library,  and  some 
technical  services  for  wiring,  air-conditioning,  etc. 

1.4.  CSERIAC  Resources 

As  called  for  in  the  Statement  of  Work,  CSERIAC  provided  staffing  for  this  Special  Task. 
In  addition  to  administrative  support  from  UDRI  and  the  CSERIAC  Associate  Director  and 
clerical  staff  as  necessary,  the  designated  CSERIAC-CAT  team  consisted  of  four  technical 
personnel.  These  were  a  full-time  Task  Manager,  a  full-time  Systems  Manager,  a  half-time 
Human  Factors  Engineer  Crew  System  Analyst,  and  a  part-time  Software  Engineer.  UDRI 
also  loaned  surplus  furniture  to  augment  the  Government  furnishings  in  the  CAT  Room. 
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2.1.  General  Management 


During  the  first  and  second  quarters  of  this  contract  period,  in  anticipation  of  the  delivery  of 
the  CAT  hardware  and  software  systems  from  Boeing,  general  plans  were  formulated  and 
key  personnel  were  hired  and  briefed  on  the  project.  [5.4.] 

At  the  beginning  of  the  third  quaner,  following  the  Boeing  training  course  in  December 
1989,  the  computer  equipment  was  moved  and  reconfigured  several  times  between  Room  8 
(the  CSERIAC  general  offices)  and  the  CAT  Room  in  attempts  to  establish  an  adequate 
work  space.  Difficulty  controlling  the  temperature  in  the  CAT  Room  and  vulnerability  to 
lightning  and  power  surges  were  evident  from  the  beginning  and  addressed  continually  by 
CSERIAC.  On  20  August  1990  Government  personnel  installed  a  drop-out  relay  and 
during  the  following  week  they  replaced  a  lower  window  with  an  air-conditioning  unit. 
[5.4.1 

Several  basic  procedures  for  facilitating  and  controlling  the  use  of  the  CAT  Room  and  CAT 
tools  by  other  than  CSERIAC  personnel  were  put  in  place  early  on.  User  Accounts  were 
installed  on  all  systems,  and  a  Scheduling  Calendar  and  Activities  Log  Notebook  (for 
documenting  use  by  non-CSERIAC  designers  and  engineers)  were  instituted.  [5.4.] 

A  working  meeting  between  a  few  Government  and  CSERIAC  personnel,  preliminary  to  a 
formal  Kick-Off,  was  held  on  1 1  January  1990  at  which  an  outline  describing  the  status  of 
CAT  equipment  and  CSERIAC  activities  and  goals  was  presented  and  discussed.  Thirteen 
people  attended  the  Kick-Off  on  9  February.  A  top-level  early  version  management  chart 
was  presented  and  discussed,  goals  were  clarified,  and  areas  of  particular  concern  were 
noted.  Three  action  items  were  identified:  (1)  compilation  of  inventories  for  current  in- 
house  software,  hardware  and  documentation;  (2)  delivery  of  a  schedule  chart  showing 
milestones  for  the  entire  CAT  Special  Task;  and  (3)  establishment  of  configuration  control 
procedures,  methods,  and  tools.  [5.4.] 

An  inventory  of  CAT  software  was  delivered  to  the  CAT  ADPO  on  22  February  1990; 
inventories  for  hardware  and  documentation  followed  on  30  March.  The  first  of  several 
editions  of  a  CAT  Management  Plan  Schedule  Chart  (PERT  Diagram)  and  accompanying 
Task  Timeline  (Gantt  Chart)  were  delivered  to  the  CAT  ADPO  and  other  Government 
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personnel  at  about  the  same  time  (6  March).  The  task  of  controlling,  documenting  and 
tracking  both  hardware  and  software  configuration  changes  was  analyzed,  methods  and 
procedures  were  defined,  and  a  Macintosh  database  management  system  was  identified 
within  which  a  configuration  control  database  could  be  built,  maintained  easily,  and 
accessed  by  ar;  opnate  management  personnel  both  at  CSERIAC  and  at  AAMRL/HE. 
15.4.1 

Also  in  mid  February  1990,  initial  contact  and  good  rapport  was  established  with  the 
Deputy  Project  Manager  for  CAT  at  Boeing  in  Seattle.  This  rappon  continued  throughout 
the  contract  period  with  excellent  cooperation  demonstrated  continually,  not  only  between 
the  two  prime  Points  of  Contact  (the  Boeing  Deputy  Project  Manager  and  the  CSERIAC 
Task  Manager),  but  in  all  contacts  between  Boeing  and  CSERIAC  technical  personnel. 
Several  drafts  of  an  Associate  Contractor's  Agreement  were  exchanged  between  respective 
contracts  offices  during  the  following  months.  A  formal  document  was  signed  by  both 
panies  in  November,  though  the  relationship  had  been  adequately  served,  informally,  from 
the  beginning.  |5.4.,  5.5.) 

The  first  of  several  discussions  concerning  the  status  of  the  current  project  and  the  need  to 
extend  and  expand  its  objectives  took  place  in  May  of  1990.  Directly  afterwards  a  memo 
proposing  personnel  allocation  and  funding  for  an  additional  year  of  effon  was  delivered  to 
the  CAT  ADPO.  At  the  same  time,  CSERIAC-CAT  management  personnel  drafted  the  first 
of  several  documents  suggesting  amendments  to  the  original  Statement  of  Work  that  were 
more  consistent  with  the  direction  and  time-frame  of  the  project  as  it  had  actually  developed 
and  war  expected  to  develop  in  the  future.  Later  versions  of  this  document  formed  the 
basis  of  a  request  to  DESC  suggesting  details  for  a  Contract  Modification.  This  request 
noted  that  the  realities  of  working  with  a  developmental  prototype  conflicted  with  fulfilling 
several  tasks  delineated  in  the  original  SOW,  whose  objectives  would,  in  fact,  be  best 
served  after  final  versions  of  the  CAT  tools  were  released.  This  Contract  Modification  was 
granted  by  DESC  in  late  November.  (5.1.,  5.4.] 

In  summary,  the  CSERIAC-CAT  general  management  goals  were  to  fulfill  the 
requirements  of  the  Special  Task  contract  by  (1)  establishing  a  cohesive  team  of  technical 
personnel  and  facilitating  their  acquisition  of  expertise  in  the  function  and  use  of  the  CAT 
software;  (2)  establishing  procedures  and  aids  for  continued  management  of  CAT  at 
CSERIAC,  including  configuration  control  and  suppon  for  the  use  of  CAT  by  the  technical 
design  community;  (3)  establishing  a  working  relationship  with  the  developers  of  the  CAT 
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tcx)Is;  and  (4)  evaluating  and  critiquing  the  CAT  software  in  terms  of  its  usability  and 
applicability  insofar  as  possible,  given  its  stage  of  development.  All  of  these  goals  have 
been  met.  [5.1.,  5.4.) 

2.2.  Configuration  Control 

The  hardware  and  software  systems  delivered  in  October  and  December  of  1989  were 
configured  initially  to  accommodate  the  training  course.  A  truly  workable  configuration 
that  allowed  for  multi-user  access  and  file  transfer  between  the  component  systems  was  not 
instituted  until  early  March  when  a  new  Systems  Manager  assumed  full-time  duties.  The 
month  of  March  was  extremely  busy  and  productive;  several  hardware  failures  were 
detected  and  corrected,  and  several  software  problems  were  solved.  File  transfer 
capabilities  between  MERLIN,  WREN  and  CATBIRD  were  established,  and  protected  user 
accounts  on  all  systems  were  set  up  and  tested.  Additionally,  as  noted  above,  inventories 
of  all  hardware,  software  and  documentation  items  were  produced  and  delivered  to  the 
CAT  ADPO  in  February  and  March.  [5.4.  j 

Also  in  March,  directory  listings  for  each  of  the  three  systems  were  printed  out  and  sent  to 
Boeing  in  efforts  to  determine  optimum  configuration  for  all  the  software.  Boeing  analysts 
quickly  confirmed  that  the  configurations  that  had  been  hastily  set  up  for  the  training  course 
were  inadequate  for  practical  use  and,  working  with  the  CSERIAC-CAT  Systems 
Manager,  were  helpful  in  suggesting  changes.  [5.4.] 

A  review  of  options  concerning  hardware  sites  and  configurations,  along  with  projections 
of  current  and  future  disk  space  needs,  made  clustering  the  two  VAX  systems  imperative. 
All  user  accounts  and  both  VAX  operating  systems  were  placed  on  MERLIN  disk  packs; 
only  paging  files  and  the  I-DEAS  CAD/CAM  software  were  left  on  WREN's  three  RD  disk 
drives.  Unusable  hardware  (such  as  an  RA-81  drive  not  usable  on  MERLIN  without  a 
new  bus  controller)  were  turned  over  to  AAMRL/HE.  Setting  up  the  rooted  directories  and 
the  printer  and  batch  queues  in  the  new  environment,  the  main  subtasks  associated  with 
clustering  the  VAXes,  turned  out  to  be  a  bit  more  involved  than  expected  but  were 
successfully  accomplished.  [5.4.] 

Networking  the  two  VAXes  to  the  IRIS  workstation  with  WIN/TCP,  the  Wollongong 
TCP/IP  network  software,  had  been  accomplished  earlier  but  had  to  be  repeated  because  of 


6 


changes  in  disks  and  disk  drive  names  associated  with  the  new  cluster  environment.  This 
also  turned  out  to  be  somewhat  problematic  due  to  incompatibilities  between  the  WIN/TCP 
and  the  VAX  5.3-1  0/S,  but,  again,  was  successfully  accomplished  by  early  summer. 
During  the  last  quarter  of  the  contract  period  (September-December  1990)  all  AAMRL 
computers  were  configured  for  Internet  access,  with  concomitant  changes  in  all  node 
addresses.  This  caused  some  disruption  in  our  local  network  and  cluster,  and  quite  a  lot  of 
rebuilding  was  necessary  yet  again.  [5.4.] 

Hardware  failures  occurred  fairly  regularly,  though  not  excessively.  On  average,  one  or 
two  were  dealt  with  each  quarter.  Maintenance  personnel  from  the  appropriate  vendors 
(DEC  or  Silicon  Graphics)  responded  quickly;  in  most  instances  faulty  components  were 
replaced  under  existing  support  contracts.  [5.4.) 

Operating  system  software  upgrades  were  installed  as  they  were  acquired.  From  early 
March  until  the  end  of  December  1990,  upgraded  VAX/VMS  operating  systems  had  been 
installed  for  MERLIN  and  WREN  three  times,  and  upgraded  IRIX  operating  systems  for 
CATBIRD  had  likewise  been  installed  three  times.  A  complete  system  generation  with 
reinstallation  of  all  products  was  done  once  for  each  of  the  two  operating  systems.  [5.4.] 

There  were  several  important  updates  to  applications  software  as  well,  with  most  of  the 
activity  occurring  in  the  spring.  Updates  to  commercial  packages  (Ingres,  MDTOOL  and 
I-DEAS)  were  regularly  received,  but  only  those  evaluated  and  implemented  by  Boeing 
were  installed  as  working  versions.  MDTOOL  version  3.05  was  installed  by  Merit 
Technology  personnel  on  12  June.  That,  together  with  the  companion  upgrade  to  the 
Boeing  software  which  was  delivered  soon  after,  became  our  first  operating  baseline  and 
was  dubbed  CAT  [3-1  (Beta-1).  The  Boeing  tape  included  some  changes  to  the  CASS 
modules  and  to  lATOOL,  two  new  versions  of  NMT  (one  compatible  with  the  new  format 
for  the  flight  data  recorder  file  and  the  other  compatible  with  the  old  format  of  that  file),  and 
some  database  files  compatible  with  the  new  MDTOOL.  1-DEAS  4.1,  Ingres  6.2,  and  the 
VAX/VMS  5.3-1  and  IRIX  3.2  operating  systems  are  the  other  basic  components  of  CAT 
[3- 1 .  Towards  the  end  of  the  year  Boeing  sent  a  considerable  number  of  data  files 

compatible  with  MDTOOL  3.08,  around  which  we  are  expecting  to  build  the  next  update  of 
the  CAT  tools,  CAT  p-2.  [5.4.] 

Beginning  in  the  spring  and  continuing  through  to  early  December,  considerable  effon  was 
spent  in  the  pursuit  of  providing  and  maintaining  support  agreements  (licensing)  with 
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various  hardware  and  software  vendors.  These  vendors  include  Ingres,  Merit  Technology 
(for  MDTOOL),  SDRC  (for  1-DEAS),  Tektronix,  Hewlett-Packard,  Wollongong  (for 
TCP/IP),  Interleaf  (for  the  Tech  Pub  S/W),  Precision  Visuals  (for  the  DI-3000  Graphics 
S/W),  Microsystems  (for  Mass-1 1  Word  Proc  S/W),  and,  of  course,  DEC  and  Silicon 
Graphics.  Itemized  lists,  including  model  numbers  and  pricing  information,  were  delivered 
to  the  CAT  ADPO  as  the  information  was  collected  and  organized.  Additionally,  several 
times  during  the  year,  the  CSERIAC-CAT  Systems  Manager  alerted  the  CAT  PO  in  writing 
(or  E-Mail)  to  potential  problems  or  needs  with  respect  to  both  hardware  and  software  that 
should  be  considered  for  optimum  continuous  support  of  the  CAT  systems.  [5.4.] 

A  preliminary  schema  for  the  configuration  control  database  (called  CATCON)  was 
designed  and  installed  in  FoxBASE-»-/Mac,  a  Macintosh-platform  multi-user  version  of  a 
DBMS  owned  by  CSERIAC.  Besides  its  touted  speed  and  other  state-of-the-art  features, 
this  DBMS  was  chosen  because  PC  versions  of  FoxBASE  can  network  with  the  Mac 
versions,  allowing  maximum  access.  Preliminary  descriptions  and  plans  for  developing 
this  database  were  presented  at  the  kick-off  meeting  in  early  February  and  a  first-draft 
schema  (listing  field  names,  data  types,  and  descriptions  of  contents)  was  included  in  the 
fourth  CAT  Quarterly  Technical  and  Configuration  Control  Reports  covering  April-June. 
[5.4.]  A  formal  (written)  Configuration  Control  Plan  including  more  detailed  descriptions 
along  with  projections  of  content  and  use  was  delivered  to  the  CAT  ADPO  on  20 
November  and  is  included  in  the  Appendices  as  Section  6.1.  [5.6.] 

2.3.  Development  of  Proficiency  and  Training 

Establishing  expertise  in  the  use  of  the  CAT  tools  has  been  a  major  and  continual  thrust  at 
CSERIAC.  Paralleling  this  effort  has  been  the  development  of  training  concepts,  methods 
and  aids,  since  that  which  is  learned  by  CSERIAC-CAT  will  subsequently  be  taught  by 
CSERIAC-CAT.  Exposure  to  the  basic  components  and  concepts  of  the  Boeing  CAT 
program  began  before  the  actual  training  course  in  December  1989,  though  no  hands-on 
expierience  was  possible  before  delivery  and  configuration  of  the  hardware  and  software. 
After  the  training  course,  and  after  a  working  environment  and  stable  multi-user 
configuration  was  achieved,  progress  in  these  areas  increased  dramatically.  By  early 
February  the  CSERIAC-CAT  Analyst  had  exercised  all  of  the  tools  on  both  graphics 
workstations  from  the  single  user  account  active  at  that  time.  On-line  procedural 
documentation  was  generated  for  each  module,  so  that  lessons  learned  while  acquiring 
proficiency  could  be  used  in  critiquing  the  tools,  developing  training  concepts  and 
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materials,  and  transferring  the  technology-  applying  CAT  to  the  cockpit  design  process. 
(5.4.1 


Hands-on  exercising  of  the  tools  was  slowed  during  the  early  spring  due  to  the  large 
amount  of  system  reconfiguration.  However,  a  short  review  of  CAT  capabilities  was  given 
to  HSD/Y AH  and  WRDC/KTC  personnel,  and  progress  was  made  in  analyzing 
possibilities  and  developing  strategy  for  the  first  formal  proficiency  demonstration.  The 
F-16C  cockpit  was  selected  as  the  subject  for  this  demonstration,  and  some  relevant 
material  was  acquired—  (hard  copy)  F-16  scenarios  from  HSDA'AH,  and  a  tape  from 
Boeing  containing  several  directly  relevant  input  files.  [5.4.] 

Throughout  the  contract  period,  as  the  CSERIAC-CAT  Analyst  concentrated  on  developing 
proficiency  in  using  the  CAT  modules,  the  Systems  Manager's  main  thrust  was  increasing 
his  general  knowledge  of  the  hardware  and  software  systems  under  his  care  and  in 
computer  graphics,  particularly  CAD/CAM.  In  practice,  each  of  these  CSERIAC-CAT 
team  members  served  as  the  other's  main  "back-up,"  lending  depth  to  team  expertise. 

During  the  second  half  of  1990  all  efforts  in  developing  proficiency,  developing  materials 
which  could  be  used  for  demonstration  and  training  later  on,  and  analyzing  the  limitations 
or  bugs  in  the  CAT  software  were  specifically  tuned  to  preparations  for  the  formal 
demonstration  of  CSERIAC-CAT  proficiency  and  CAT  capabilities.  An  Organizational 
Plan  and  Agenda  for  the  demonstration  was  delivered  to  the  CAT  ADPO  on  5  September. 
Subsequent  meetings,  both  intra-CSERIAC  and  between  CSERIAC-CAT  people  and  CAT 
ADPO  personnel,  helped  develop  a  somewhat  realistic  engineering  design  problem  as  the 
focus  of  the  demonstration.  CAT  ADPO  personnel  and  personnel  of  HSDATi  were 
particularly  helpful  in  supplying  technical  guidance  for  developing  the  Air-to-Ground  (A/G) 
mission  scenario  and  generating  the  event  time  line.  Other  ASD  technical  personnel,  and 
technical  personnel  at  Merit  Technology  and  at  Boeing,  also  helped  in  various  ways 
towards  preparation  of  this  example  design  problem  for  the  demonstration.  [5.4.] 

The  formal  "Demonstration  of  CAT  Software  Tool  Capability  and  CSERIAC-CAT 
Proficiency  Using  an  Engineering  Cockpit  Design  Problem"  was  given  on  19  December  in 
the  CAT  Room  at  CSERIAC.  A  total  of  10  people  attended.  On  30  October,  seven  weeks 
before  the  demonstration,  a  draft  narrative  of  the  engineering  design  problem  was  delivered 
to  the  CAT  ADPO.  A  revised  (and  final)  versiort  was  delivered  on  18  November. 
Additionally,  as  an  offshoot  of  the  successful  year-long  effort  to  document  procedures  used 
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in  applying  CAT  to  design  problems  in  general  (an  integral  part  of  our  Training  and 
Technology  Transfer  efforts),  the  CSERIAC-CAT  Analyst,  with  team  cooperation, 
produced  a  94-page  document  which  describes,  specifically  for  the  example  design 
problem  used  in  this  demonstration,  the  analyses  steps,  results,  and  recommendations  for 
design  changes;  notes  bugs  and  limitations  of  the  CAT  tools  encountered;  and  includes  67 
pages  of  appendices  containing  sample  output  and  descriptions  specific  to  this  problem  and 
these  analyses.  [5.4.,  5.7] 

On  the  day  following  the  formal  demonstration,  a  Workshop  Plan  was  delivered  to  the 
CAT  ADPO.  Actual  presentation  of  a  training  workshop  during  this  year  (a  requirement  of 
the  original  Statement  of  Work),  was  deemed  unwise  largely  because  of  the  current 
developmental  state  of  the  CAT  software,  so  that  SOW  item  was  amended  appropriately. 
The  final  distribution  version  of  CAT  software  is  not  expected  from  Boeing  until  the  end  of 
1991;  evaluation  of  it  and  the  building  of  support  files  (databases  and  CAD  data  sets)  will 
take  some  time  after  that.  For  these  reasons,  the  thrust  of  this  Workshop  Plan  was 
preliminary  and  offered  very  basic  and  theoretical  options  in  scopie,  time-frame,  design, 
and  course  content.  [5.4.,  5.8.) 

2.4.  Technology  Transfer 

Areas  of  concern  at  CSERIAC-CAT  have  all  along  been  seen  as  interdependent  and 
intertwined.  That  is,  we  have  acknowledged  that  management  of  the  special  task, 
configuration  control  and  systems  management,  development  of  proficiency  and  training, 
and  transfer  of  the  CAT  technology  to  the  engineering  design  community  are  interrelated 
and  that  the  categories  exist  mainly  for  administrative  and  reporting  purposes,  often  with  no 
clear-cut  boundaries  between  them.  Consequently,  we  have  never  treated  them  linearly; 
technology  transfer  strategies-  indeed,  marketing  strategies  in  addition—  have  been 
considered  from  the  very  beginning  as  parallel  concerns  along  with  the  development  of 
proficiency  and  training  methods/procedures,  even  though  we  have  been  working  entirely 
with  a  pre-release  version  of  the  technology. 

At  the  end  of  February  1990,  in  response  to  a  request  from  AAMRL/HED,  a  user  account 
was  set  up  for  an  LTSI  analyst  so  that  the  CAT  modules,  particularly  MDT(X)L,  could  be 
exercised  with  "real-world"  data.  Soon  afterwards,  user  accounts  were  set  up  for 
personnel  of  ASD/ENECH,  ASD/ENECH-CSEF,  and  CAE-Link  so  that  they  could 
investigate  the  use  of  CAT  in  redesigning  the  C130-J  cockpit.  A  User  Activity  Log  in  the 
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form  of  a  loose-leaf  notebook  with  preprinted  forms  was  instituted  to  keep  track  of  activity, 
and  the  standard  AFSC  Form  2685  implemented  to  receive  requests  for,  and  maintain 
records  of,  access  to  the  CAT  computers.  [5.4.] 

Several  informal  demonstrations  have  been  given,  with  CAT  ADPO  approval,  to  industry 
and  USAF  groups  investigating  the  potential  of  using  CAT  in  crew  station  design.  R&D 
personnel  from  the  Ford  Motor  Company  visited  CSERIAC  in  mid  May  of  1990.  Two 
personnel  of  AFHRL/LR  were  given  a  short  demonstration  in  July.  In  August,  MDTOOL 
was  demonstrated  for  several  members  of  HSDA"AH(NSBIT),  and  the  Branch  Chief  of 
AAMR17BBE.  And  in  mid  October,  personnel  of  NTI  and  of  Fighter  Command 
International  attended  a  demonstration  of  MDTOOL  and  discussed  CSERIAC  capabilities 
for  database  maintenance  and  design.  Informal  demonstrations  have  been  given,  as 
requested  by  the  CAT  ADPO,  for  various  AAMRL/HEX  personnel.  [5.4.] 

SABER  Lab  personnel  have  borrowed  copies  of  MDTOOL  and  related  files  to  support  their 
own  separate  efforts.  Likewise,  ASD/ENECH  and  CAE-Link  personnel  have  continued  to 
exercise  MDTOOL  for  other  projects;  in  October  and  November  they  evaluated  KC- 1 35 
Air-to-Air  (A/A)  scenarios  provided  by  Boeing  in  the  hopes  of  applying  them  to  a  redesign 
effort  for  that  aircraft.  Another  ASD/ENECC  engineer  and  a  WL/KTC  engineer  have  also 
continually  exercised  MDTOOL,  with  technical  support  from  CSERIAC-CAT.  [5.4.] 

The  procedures  Notebook  represents  a  long-term  effort  and  a  significant  accomplishment. 

It  evolved  as  an  integrated  attempt  by  the  CSERIAC-CAT  Analyst  to  address  issues  in 
providing  guidance  and  documentation  during  actual  applications  of  CAT,  in  developing 
aids  for  training  and  technology  transfer,  and  in  documenting  the  analyses  performed  for 
the  engineering  design  example  used  in  the  formal  demonstration.  It  parallels  the 
Designer's  Electronic  Notebook  (DEN)  being  developed  by  Boeing  as  part  of  CAT  and 
serves  similar  functions.  At  CSERIAC,  each  "template"  version  of  the  Procedures 
Notebook  will  serve  to  guide  the  analyst  and  designer  through  the  use  of  the  CAT  tools 
during  the  analyses  process.  When  the  analysis  is  complete,  the  Notebook  serves  as  a 
tracking  mechanism  for  shifting  to  alternative  designs  and  further  analyses,  and  for 
documenting  an  acceptable  design  change.  Design  engineers  using  CAT  P-21  (Beta-2 
Interim)  at  CSERIAC  to  investigate  specific  problems  have  been  provided  with  template 
versions  of  the  Procedures  Notebook.  [Section  6.2.]  We  plan  continual  improvement  and 
further  evolution  of  this  particular  aid  to  using  CAT.  [5.4.,  5.9.] 
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Another  aspect  of  the  transfer  of  CAT  technology  to  the  user  community  is  its  marketing. 
Early  on,  during  the  kick-off  meeting  on  9  Febic.iry  1990  and  in  follow-up  informal 
meetings,  a  good  idea  (originating  with  a  member  of  AAMRL/HEG)  for  helping  to 
organize  the  marketing  of  CAT  at  CSERIAC  via  a  "CAT  Product  Inventory  Data  Base"  was 
discussed.  The  database  would  help  to  define  CSERIACs  role  in  distributing  services  and 
"hard"  products-  promotional  or  explanatory  documents,  software  and  data  files  (CAT,  or 
CAT-related),  specifications  for  commercial  hardware  and  software  needed  to  run  CAT, 
etc.  Customer  tracking  would  be  another  function  of  the  database,  so  that  profiles  of 
customer  activity  within  and  outside  of  the  DoD  would  be  available.  Although  this 
database  has  not  developed  beyond  the  idea  stage  during  this  contract  period,  its  potential  is 
recognized  and  further  development  is  planned. 

2.5.  Library  of  Documentation 

A  library  of  CAT  documentation,  each  item  of  which  is  direcdy  related  to  a  panicular  piece 
of  CAT  hardware  or  software,  is  maintained  in  the  CSERIAC  office  or  CSERIAC-CAT 
Room.  No  technical  documentation  that  is  specific  to  the  Boeing-developed  CAT  tools  has 
been  delivered  yet,  of  course,  but  current  versions  of  user's  manuals  and  installation 
instructions  for  all  commercial  products  are  available.  A  few  second-source  textbooks  (on 
Ingres,  for  example)  are  also  in  the  CSERIAC  CAT  Library.  Each  piece  of  documentation 
will  eventually  be  represented  in  the  configuration  control  database  (CATCON),  in  the 
record  for  the  hardware  or  software  item  to  which  that  documentation  relates.  Eventually, 
each  will  be  tagged  with  a  suitable  control/ownership  code.  [5.2.,  5.4.,  5.6.] 

2.6.  Related  Effort:  AAMRL/HEG  CAT  Library  &  Database 

An  additional  accomplishment,  not  specified  in  the  SOW  but  seen  as  contributing  to  the 
overall  objectives  of  CAT,  was  the  estiblishment  of  a  bibliographic  database  and  library  for 
literature  on  Cockpit  Automation  Technology  (CAT).  The  library  itself  is  currently  located 
at  AAMRL/HEG.  CSERIAC  performed  an  extensive  bibliographic  search  to  help  identify 
relevant  documents,  then  helped  acquire  those  designated  by  HEG  personnel.  [5.4.] 

The  database  uses  the  Ingres  Database  Management  System  that  supports  the  CAT  software 
tools  and  is  mounted  on  MERLIN,  VAX  8250.  CSERIAC-CAT  team  members  with 
expertise  in  database  design  helped  determine  requirements  and  specifications.  The 
database  schema  was  installed  in  late  summer  and  has  the  name  HE_CAT_LIBRARY_DB. 
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HEG  personnel  were  provided  with  field  descriptions  and  given  a  training  session  (using 
their  own  computer  terminals  to  access  MERLIN)  in  August.  [5.4.  J 

Though  not  fully  developed,  this  related  project  is  seen  as  a  valuable  asset  to  the  overall 
CAT  mission.  It  provides  a  "close-by,"  highly  selective  and  highly  relevant  bibliography 
and  library  of  technical  literature  on  Cockpit  Automation  Technology,  within  easy  reach  of 
the  designers  and  engineers  who  need  it. 


As  previously  stated,  an  important  general  goal  was  to  evaluate  and  critique  the  CAT 
software  in  terms  of  its  usability  and  applicability,  given  its  prototype  stage  of 
development.  Attention  was  given  to  this  objective  during  all  interactions  and  exercising  of 
the  CAT  tools,  but  comprehensive  evaluations  and  documentation  thereof  were  actually 
accomplished  during  the  development  of  the  formal  "Demonstration  of  CAT  Software  Tool 
Capability  and  CSERIAC-CAT  Proficiency  Using  an  Engineering  Cockpit  Design 
Problem".  [5.7.1 

3.1.  The  CAT  Methodology 

The  overall  objective  of  the  Air  Force’s  CAT  Program  is  to  "develop  and  demonstrate  a 
totally  integrated  crew  system  design  and  evaluation  process  applicable  to  manned  military 
flight  vehicles".  To  meet  this  objective,  Boeing  Advanced  Systems,  for  their  part, 
developed  a  structure  for  this  integrated  process  (the  Methodology)  and  complemented  it 
with  the  Designer's  Computer  Aided  Design  System  (DCADS),  the  CAT  software  tools. 

The  Boeing-developed  CAT  Methodology  is  depicted  in  IDEFq  format  as  a  two-level  flow 
structure  where  the  top  level  consists  of  function  blocks  and  the  second  level  consists  of 
procedures  specific  to  each  function  block  that  must  be  performed  to  obtain  the  necessary 
input  for  the  next  function  block.  Boeing  has  developed  groups  of  function  blocks  for  each 
of  four  processes  (sometimes  called  "phases"  or  "stages"  in  the  Boeing  documentation)— 
Analysis,  Design,  Test  &  Evaluation,  and  ILS  &  Safety-  within  each  of  the  four  weapon 
system  development  phases  of  the  Department  of  Defense  major  systems  acquisition 
process  (MSAP).  These  four  weapon  system  development  phases  are:  Concept 
Definition,  Demonstration/Validation,  Full  Scale  Development,  and  Test  &  Evaluation. 

The  Boeing  CAT  Methodology,  thus,  is  encompassed  within  a  matrix  of  16  different 
groups  of  top-level  function  blocks  (See  Figure  1). 

The  group  of  function  blocks  within  the  DemonstrationA^alidation  column  (phase)  and 
Analyses  row  (process)  appeared  to  be  the  most  appropriate  for  the  feasibility-study  type  of 
analyses  most  likely  to  occur  at  CSERIAC-CAT  in  the  future,  and  for  those  needed  in  the 
example  problem  of  the  CSERIAC-CAT  formal  demonstration.  Although  not  all  of  the 
top-level  function  blocks  were  executed  or  reviewed  for  that  particular  problem,  the 
complete  list  for  that  cell  of  the  Methodology  structure  is  as  follows: 


DEMONSTRATIONA^ALIDATION  Column,  ANALYSIS  Row: 


DAOl.  Develop  Human  Engineering  Plan; 

DA02.  Conduct  Mission  and  System  Analysis; 

DA03.  Characterize  Mission; 

DA04.  Define  Baseline  Crew  Station; 

DAOS.  Generate  Control/Display  Catalog; 

DA06.  Perform  Function  Analysis; 

DA07.  Attach  Tasks  to  Procedures; 

DAOS.  Perform  Procedure  Analysis; 

DA09.  Perform  Reach  Analysis; 

DA  10.  Perform  Internal  Vision  Analysis; 

DA  1 1 .  Perform  External  Vision  Analysis; 

DA  1 2.  Perform  Workload  Analysis; 

DA  13.  Perform  Information  Analysis; 

DA  1 4.  Review  Configuration  and  Rework  or  Accept; 

DAIS.  Perform  Critical  Task  Analysis; 

DA  1 6.  Review  Go-  Ahead  for  Evaluation; 

DA  1 7.  Perform  Function  Analysis; 

DA  1 8.  Evaluate  Design  Solution  Candidates; 

DA  1 9.  Define  Control  and  Display  Requirements; 

DA20.  Define  Operational  Procedures; 

D A2 1 .  Establish  Equipment  Requirements; 

DA22.  Document  Human  Engineering  Results. 

The  CAT  Methodology  provides  a  logical  framework  in  which  to  establish  procedures  for 
performing  human  engineering  analysis  of  crew  station  design.  For  the  demonstration 
design  problem,  the  procedures  attached  to  the  function  blocks  considered  were  thorough 
in  addressing  all  possible  areas  of  analysis.  However,  the  methodology  failed  to  provide 
help  in  determining  whether  or  not  certain  procedures  might  actually  need  to  be  performed 
at  all  in  a  particular  analysis,  why,  or  which  procedures  might  most  readily  be  shed.  The 
Methodology  also  fails  to  identify  a  starting  point  for  the  analyses  and  to  indicate  what 
resources  are  required  to  obtain  specific  analytical  output  that  might  be  desired. 


15 


UlEflPON  SVmM  DEUELQPMENT  PHRSES 


Figure  1. 


3.1.1.  Applicability  to  Design  Process 

To  perform  the  analyses  for  the  demonstration  problem,  and  for  future  analyses,  a 
procedures  notebook  was  developed  to  keep  records  of  the  software  tools  accessed, 
required  inputs,  outputs,  file  naming  for  traceability,  lessons  learned,  and  results  leading  to 
design  documentation  and  specifications.  This  notebook  complements  the  CAT 
Methodology  developed  by  Boeing  and  maintains  a  record  of  the  analyses  activities  for 
traceability  and  for  providing  any  information  necessary  for  documentation.  Though 
somewhat  cumbersome  in  its  current  paper  format,  it  serves  an  important  function  by 
providing  a  prototype  and  guide  for  future  crew  station  design  activities.  [5.9.] 

Given  the  structure  of  the  Boeing  CAT  Methodology  and  that  the  example  design  problem 
analysis  was  to  be  performed  within  the  DemA^al  phase,  the  procedures  notebook  was 
divided  into  sections  conresponding  to  the  top-level  functions,  the  procedures  for  each  of 
those  functions  were  then  listed  and  specific  information  was  entered  for  each  procedure. 
This  worked  well  for  the  demonstration  design  problem.  [5.7.]  The  CAT  Methodology  did 
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provide  a  logical  sirucaire  for  execution  of  the  analysis  process.  The  most  noteworthy 
problem  in  applying  the  CAT  Methodology  to  the  design  process  is  the  lack  of  feedback 
loops  for  iterative  processes.  The  current  CAT  Methodology  is  uni -directional  and  will  not 
accomnxxiate  parallel  or  iterative  processes. 

3.1.2.  Relationship  to  the  CAT  Software  Tools 

The  software  tools  (DCADS)  may  be  used  to  obtain  output  files  leading  to  products  for 
several  procedures  of  the  top-level  functions  in  the  CAT  Methodology.  Those  that  support 
the  top-level  functions  for  the  example  design  problem  are  given  below; 

DA02.  Conduct  Mission  and  System  Analysis  -  Mission  Decomposition  Tool 
(MDTOOL); 

DA03.  Characterize  Mission  -  MDTOOL; 

DA04.  Define  Baseline  Crew  Station  -  Cockpit  Instrument  Panel  Layout 
Program  (CIPLP); 

DAOS.  Generate  Control/Display  Catalog  -  CEPLP; 

DA06.  Perform  Function  Analysis  -  Network  Management  Tool  (NMT); 

DA07.  Attach  Tasks  to  Procedures  -  NMT; 

DAOS.  Perform  Procedure  Analysis  -  NMT; 

DA09.  Perform  Reach  Analysis  -  Operator  Assessment  of  Reach  (OAR); 

DA  10.  Perform  Internal  Vision  Analysis  -  Display  Legibility  Analysis  (DLA); 
DA  1 1 .  Perform  External  Vision  Analysis  -  E- VISION; 

DA  12.  Perform  Workload  Analysis  -  Procedure  Execution  Time  (PET), 
Mission  Scenario  Analysis  (MSA),  Mission  Procedure  Execution 
(MPE),  Mission  Time-Line  Analysis  (MTA),  Mission  Task  Time 
Performance  (MTP),  Function  Analysis  Report  (FAR); 

DA  13.  Perform  Information  Analysis  -  Information  Analysis  Tool  (lATOOL); 
DA17.  Perform  Function  Analysis  -  NMT; 

DA  1 8.  Evaluate  Design  Solution  Candidates  -  Survivability  Measures  and 
Methods  Technique  (SUMMET); 

There  is  a  very  close  relationship  between  the  CAT  Methodology  and  CAT  Software  tools. 
Although  the  CAT  Methodology  theoretically  allows  for  performing  procedures  in  any 
medium,  it  is  apparent  that  most  procedures  are  described  with  specific  software  tools  in 
mind.  For  example,  when  performing  Procedure  Analysis,  the  user  is  required  to  "Attach 
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PrcKedures  to  Functions."  This  references  a  menu  option  specific  to  the  NMT,  and  is  not 
as  meaningful  if  the  user  is  performing  this  procedure  in  another  medium  (such  as  pencil 
and  paper),  cmt  in  a  different  software  environment. 

3.2.  Software  Baseline  Version,  CAT  P-1 

As  described  in  Sections  1  and  2,  the  early  DCADS  hardware  and  software  which  was 
delivered  to  CSERIAC-CAT  December  1989  together  with  the  software  update  of  June 
1990  (MDTOOL  3.05  and  some  of  the  Boeing-developed  software  interacting  with  it) 
became  the  CSERIAC-CAT  baseline  configuration  which  we  called  CAT  P-1 .  Critique  and 
evaluation  of  this  version,  therefore,  should  be  interpreted  acknowledging  the  fact  that  both 
MDTOOL  and  the  Boeing  software  were  still  in  developmental  phases  at  this  time. 

3.2.1.  Relationship  to  the  CAT  Methodology 

Relationship  of  the  CAT  software  tools  to  the  Methodology  is  best  described  by  noting  the 
functionality  of  each  tool  as  implementation  of  a  particular  part  of  the  Methodology.  The 
Mission  Decomposition  Tool  (MDTOOL)  allows  one  to  graphically  plan  a  mission, 
decompose  it  into  analyses  subsets  or  phases,  and  analyze  it  phase  by  phase.  It  can 
generate  planned  and  perspective  view  maps  based  on  Defense  Mapping  Agency  (DMA) 
Digital  Terrain  Elevation  Data  (DTED)  and  Digital  Feature  Analysis  Data  (DFAD);  set  up 
and  display  complete  mission  scenarios,  including  terrain,  flight  path,  FEBA,  and  threat 
parameters;  evaluate  mission  scenarios  for  threat  exposure,  terrain  masking,  and  terrain 
following;  and  generate  an  event  timeline  (flight  data  recorder  file).  After  an  event  timeline 
is  generated,  the  user  may  add  or  delete  events,  tailoring  the  timeline  further  to  represent 
more  realistically  the  sequence  of  events  in  the  true  scenario.  MDT(X)L  supports  the 
following  top-level  functions  of  the  Methodology:  Conduct  Mission  and  System  Analyses, 
and  Characterize  the  Mission. 

For  the  demonstration  problem,  MDTOOL  was  used  to  describe  a  scenario  and  the 
objectives,  strategies,  and  performance  criteria  for  the  critical  mission  element,  and  to  create 
the  scenario  by  specifying  gaming  regions,  threats,  targets,  flight  profile,  and  flight  path. 
After  all  specifications  were  made,  the  mission  was  executed  and  a  flight  data  recorder  file 
generated.  The  flight  data  recorder  file  was  edited  to  include  appropriate  events.  MDT(X)L 
relates  well  with  the  CAT  Methodology.  It  allows  for  a  great  level  of  detail  in  mission 
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specifications  and  is  able  to  capture  each  of  the  procedures  in  the  Methodology  that  relate  to 
conducting  mission  and  system  analyses  and  characterizing  the  mission. 

The  Cockpit  Instrument  Panel  Layout  Program  (CIPLP)  helps  the  operator  set  up  the 
layout  of  the  cockpit  using  three  entities.  First,  a  panel  is  defined  as  a  mounting  surface 
and  the  user  can  enter  up  to  99  panels,  specifying  the  orientation  of  each  with  three 
orthogonal  reference  points.  Secondly,  a  module  is  defined  as  a  grouping  of  controls  and 
up  to  199  modules  can  reside  on  each  panel.  The  five  inputs  necessary  to  specify  each 
module  are  width,  height,  local  x-y  coordinates,  and  tilt  angle.  And  thirdly,  each  module 
can  contain  99  control/indicators.  To  define  a  control/indicator  the  following  are  necessary: 
type  (alphanumeric  code  given  to  a  category  of  controls  and  indicators),  local  x-y 
coordinates  (relative  displacements  of  the  control/indicator  centers  versus  the  module  lower 
left  comer  point),  and  complexity  score  (a  numerical  value  indicative  of  how  complex  it  is 
to  operate  a  control/indicator).  CIPLP  supports  the  following  top-level  functions:  Define 
Baseline  and  Redesigned  Crew  Station,  and  Generate  Control/Display  Catalog. 

Although  CIPLP  provides  a  means  for  creating  or  editing  the  cockpit  geometry  file  that  is 
necessary  for  further  analysis,  it  is  not  instrumental  in  its  relationship  to  the  CAT 
Methodology.  We  found  that  the  procedures  established  by  the  CAT  Methodology  are 
easily  accomplished  and  ir^re  directly  facilitated  by  editing  an  existing  Cockpit 
Configuration  Control  file  using  the  EDT  editor  available  on  the  VAXstation  II/GPX 
Workstation. 

The  External  Vision  Analysis  program  (E-VISION)  provides  the  user  with  a  total  vision 
envelope  of  unobstructed  vision  from  within  the  cockpit.  It  plots  monocular  vision  from 
the  design  eye  point  (Aitoff  or  rectangular  grids).  A  total  vision  envelope  is  shown  from 
- 1 80  degrees  to  1 80  degrees  in  azimuth  and  -90  degrees  to  90  degrees  in  elevation. 
E-VISION  supports  the  external  vision  analysis  top-level  function  of  the  Methodology.  It 
directly  relates  to  this  part  of  the  Methodology  and  is  able  to  produce  all  appropriate  output 
for  the  external  vision  analysis  function. 

The  CAT  Automated  Software  System  (CASS)  is  comprised  of  a  number  of  Boeing- 
developed  programs  that  allow  the  user  to  perform  workload  and  anthropometric  analyses 
after  the  event  timeline  has  been  prepared  using  NMT  and  the  cockpit  geometry  has  been 
specified  and  formatted  using  CCC.  CASS  encompasses  the  following  software  tools: 
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NMT,  CCC,  DLA,  MCOS,  OAR,  PET.  MSA,  MPE,  MTA,  FAR,  MTP,  PLTGGP,  and 
C-SAINT. 


The  first  of  these,  NMT  (Network  Management  Tool)  interacts  with  the  user  to  develop 
and  apply  functions,  procedures,  and  tasks  to  the  mission  event  timeline  contained  in  the 
flight  data  recorder  file.  NMT  thus  aids  the  analyst  in  elaborating  the  event  timeline 
generated  by  MDTOOL  into  a  complete  timeline  description  of  crew  member  activity  down 
to  the  elementary  task  level.  It  supports  the  following  top-level  functions  of  the 
Methodology:  Perform  Function  Analysis,  Perform  Procedure  Analysis,  and  Attach  Tasks 
to  Procedures. 

NMT  was  used  to  create  an  event-function-procedurc-task  treenet  structure  from  the  event 
timeline  of  the  flight  data  recorder  file  for  the  demonstration  problem.  This  treenet  structure 
is  a  direct  result  of  performing  the  function,  procedure  and  task  analyses  required  by  the 
Methodology  at  this  point.  By  creating  this  treenet  structure,  mission  specific  data  for  this 
function  block  is  in  a  format  that  is  usable  for  further  workload  and  information  analyses. 
NMT  provides  an  excellent  means  for  organizing  and  archiving  this  kind  of  data. 

The  second  in  the  CASS  group  of  programs  listed  above,  CCC  (Cockpit  Configuration 
Control)  uses  the  output  from  the  CIPLP  program  (named,  conveniently,  *.cccin  file)  as  its 
input,  reformats  this  data  into  a  report  format  that  is  both  usable  by  the  other  workload  and 
anthropometric  software  and  readable  by  the  user.  This  program  does  not  relate  directly  to 
the  CAT  Methodology  but  is  an  intermediate  program  that  must  be  run  in  order  to  obtain 
output  from  other  software  tools  that  do  relate  directly  to  the  CAT  Methodology. 

DLA,  the  Display  Legibility  Analysis  program ,  analyzes  the  specified  panels  of  the 
cockpit  to  determine  the  character  height  of  legends  and  displayed  characters  necessary  to 
insure  legibility  from  the  eye  reference  point.  The  program  calculates  the  physical  height  of 
a  required  marking  to  make  it  subtend  a  specified  visual  angle  at  the  eye  of  an  observer 
seated  at  a  specified  location  in  the  cockpit.  DLA  simulates  realistic  head  motion  in  looking 
at  a  display  using  a  link-man  model  of  the  operator’s  head,  neck,  and  shoulders.  This 
program  supports  only  one  of  the  twelve  procedures  for  the  Internal  Vision  Analysis  top- 
level  function  of  the  Methodology. 

MCOS  is  the  Monte  Carlo  Operator  Sample  generator  that  creates  simulations  of  human 
operators  to  determine  whether  cockpit  controls  under  consideration  can  be  reached  by  a 
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specified  population.  Each  operator  is  defined  by  12  standard  anthropometric  measures. 
Operator  samples  can  be  generated  from  population  statistics  or  user  input  of  actual 
measurements  from  a  known  sample.  MCOS  is  an  optional  program  that  can  be  run  prior 
to  performing  Reach  Analysis  and  therefore  indirectly  supports  this  top-level  function. 

OAR  (Operator  Assessment  of  Reach)  performs  a  reach  analysis  for  a  specified  number  of 
operators  on  each  control  of  every  selected  panel  in  the  CCC  geometry  database  file.  Each 
operator  is  placed  at  the  design  eye  reference  point  and  the  resulting  seat  reference  point  is 
saved.  The  operator,  then  placed  at  his  seat  reference  point,  is  made  to  reach  toward  each 
control.  OAR  accumulates  and  reports  successful  and  unsuccessful  reach  attempts  for  each 
control.  Positioning  of  the  operator  and  constraints  placed  on  the  test  depend  on  the 
operator's  clothing  and  restraint  conditions.  OAR  can  perform  a  head  clearance  for  each 
operator  if  requested.  The  program  defines  four  reach  zones:  Z1 ,  non-straining  reach  with 
shoulder  harness;  Z2,  straining  reach  against  shoulder  harness;  Z3,  non-straining  reach 
with  only  a  waist  harness;  and  Z4,  full  straining  reach  while  restrained  at  the  waist  It 
calculates  and  gives  the  percent  of  the  sample  that  can  reach  each  control  within  the 
constraints  of  each  of  the  four  zones.  OAR  direcdy  supports  the  procedures  for  performing 
the  Reach  Analysis  top-level  function  of  the  CAT  Methodology. 

The  following  CAT  software  tools  support  the  Workload  Analysis  top-level  function: 

( 1 )  PET  (Procedure  Execution  Time)  calculates  the  workload  characteristics  for  isolated 
procedures  (manual  and  visual  only)  and  provides  a  quick  calculation  of  procedure 
durations. 

(2)  MSA  (Mission  Scenario  Analysis)  lists  the  timeline,  frequency  of  use  statistics  for 
the  devices,  and  reformats  the  timeline  for  Mission  Procedure  Evaluation. 

(3)  MPE  (Mission  Procedure  Evaluation)  calculates  workload  statistics  for  each 
procedure  in  the  timeline  and  prepares  the  data  for  MTA,  FAR  and  MTP  (Mission  Time- 
Line  Analysis,  Function  Analysis  Report,  and  Mission  Task-Time  Probability). 

(4)  MTA  (Mission  Time-Line  Analysis)  sums  the  MPE-generated  workload  data  by  time 
interval,  identifies  workload  peaks  and  contributions,  reports  overall  workload  statistics, 
and  prepares  workload  plots. 

(5)  FAR  (Function  Analysis  Report)  produces  workload  reports  focusing  on  functions 
ather  than  procedures. 
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(6)  MTP  (Mission  Task-Time  Probability)  uses  an  alternate  workload  measure  to  look  at 
probability  of  activity  in  a  channel  each  second  of  the  timeline,  identifies  workload  peaks 
and  contributions,  reports  overall  workload  statistics,  and  prepares  workload  plots. 

(7)  PLTGGP  (Plot  via  General  Graphics  Package  Format)  displays  MTA  or  MTP 
workload  plot  files  in  2D  or  3D. 

(8)  C-SAINT  (Customized  Systems  Analysis  of  Integrated  Networics  of  Tasks) 
generates  a  summary  report  of  the  amount  of  time  the  pilot  is  rushed,  the  amount  of  time 
the  pilot  is  busy,  the  number  of  procedures  the  pilot  is  behind,  and  the  number  of 
procedures  the  pilot  skipped.  Both  average  and  peak  values  are  reported. 

Using  the  output  of  these  software  tools,  a  well-rounded  workload  analysis  can  be 
performed  which  directly  relates  to  procedures  of  the  CAT  Methodology  functions. 

The  Function  Allocation  Tool  (FALTOOL)  is  an  adaptation  of  the  commercial  software 
called  SUMMET  (Survivability  Measures  and  Methods  of  Evaluation  Technique).  This 
tool  is  a  general  purpose  trade-off  study  and  decision  aid.  The  user  identifies  a  decision 
structure,  the  program  evaluates  the  proposals  against  the  criteria,  and  rankings  are 
calculated  as  output.  This  adaptation  of  SUMMET  is  limited  to  resolving  candidate 
decisions  for  the  function  allocation  process  established  in  the  CAT  Methodology. 

The  Information  Analysis  Tool  (lATOOL)  is  an  application  of  the  database  management 
system  Ingres  that  creates  a  mission-dependent  and  cockpit  configuration-dependent 
timeline  of  information  requirements  at  the  pilot/vehicle  interface.  At  this  point  in 
CSERIAC-CAT  evaluation  of  the  Boeing  tools,  LATOOL  has  not  yet  been  reviewed 
adequately  enough  to  determine  its  relationship  to  the  CAT  Methodology  Information 
Analysis  top-level  function. 

3.2.2.  User  Interface(s) 

MDTOOL  version  3.05  is  installed  on  the  Silicon  Graphics  IRIS  4D/50G  called 
CATBIRD  which  operates  with  UNIX.  It  is  menu-driven  with  mouse  control.  All  options 
are  clear  to  the  point  of  being  self-explanatory  and  consistent,  making  this  CAT  software 
tool  veiy  user-friendly.  However,  the  user  must  be  careful  to  save  any  edited  files  prior  to 
exiting  a  menu.  It  is  very  easy  to  lose  valuable  files  because  MDTOOL  exits  menus 
without  prompting  for  a  save. 
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The  CIPLP  delivered  in  June  1990  runs  on  the  VAXstation  IiyGPX  called  WREN  (with 
VAXA^MS  0/S).  It  is  menu-driven  with  selections  made  from  the  keyboard.  CIPLP  is 
called  from  its  own  directory  and  run  separately  from  the  CAT  Analysis  Software  System 
(CASS)  which  comprises  the  workload  and  anthropometric  analyses.  CIPLP's  display 
interface  is  primitive  but  the  meaning  of  each  prompt  is  clear,  making  it  easy  to  use. 

E-Vision  is  an  I-DEAS  (CAD)  Boeing-developed  application  running  on  the  VAXstation 
Il/GPX.  It  is,  for  the  most  part,  command  driven  with  keyboard  entries.  Use  of  E-Vision 
requires  a  knowledge  of  I-DEAS  and  a  general  familiarity  with  CAD.  Some  of  the  prompts 
are  a  little  obscure;  most  are  adequately  user-friendly. 

NMT  also  runs  on  the  VAXstation  II/GPX.  It  currently  uses  the  VAX  Window  System 
with  selections  made  by  mouse.  Although  displayed  character  strings  are  small  and 
somewhat  difficult  to  read,  the  NMT  window  is  filled  with  usable  information.  Error 
messages  are  informative  and  the  user  is  forewarned  of  system  crashes  and  prompted  for 
saving  files.  All  of  this  makes  NMT  highly  user  friendly.  Unfortunately,  NMT  databases 
and  treenet  files  can  be  quite  large,  leading  to  lengthy  waits  of  up  to  1 5  minutes  for  the  user 
while  files  are  being  read.  Also,  there  is  a  large  delay  between  mouse  selection  and  screen 
response,  apparently  a  function  of  the  windowing  system.  This  can  be  a  cause  of  great 
frustration  and  increased  error. 

The  CASS  group  of  programs  are  also  installed  on  the  VAXstation  Il/GPX.  When  CASS 
is  invoked,  NMT,  CCC,  Workload  Software,  and  Anthropometric  Software  become 
available  as  menu  options.  The  menu  format  is  very  user  friendly  in  that  it  displays  to  the 
user  which  software  programs  need  input  from  others.  It  is  also  easy  to  move  through  the 
different  menu  layers  to  find  and  run  desired  programs. 

SUMMET,  likewise,  runs  on  the  VAXstation  II/GPX  and  is  menu  driven  with  selections 
made  from  the  keyboard.  The  CAT  P-1  version  is  difficult  to  use  because  it  requires 
operating  in  two  windows,  and  once  the  user  presses  <Retum>  for  the  second  window 
he/she  cannot  return  to  the  first  and  must  start  over  again  to  see  it.  A  user  must  also  be 
familiar  with  the  way  SUMMET  works,  especially  insofar  as  understanding  the  menu 
selections,  which  are  cryptic.  Improvements  made  to  SUMMET  since  the  June  1990 
delivery  supposedly  address  most,  if  not  all,  of  these  user-interface  issues,  and  these 
improvements  are  expected  to  be  evident  in  the  next  version  of  CAT  software  delivered  to 
CSERIAC. 
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lATOOL  is  also  on  the  VAXstation  II/GPX.  As  previously  mentioned,  lATOOL  is  an 
application  of  the  Ingres  database  management  system.  It  is  menu-driven  with  selections 
made  firom  the  keyboard.  Like  SUMMET,  several  improvements  have  been  made  since  its 
June  1990  delivery  making  it  more  usable  and  meaningful,  and  full  testing  and  critique  of 
this  program  is  best  reserved  for  a  subsequent  report  period. 

3.2.3.  Bugs  and  Technical  Limitations  of  Software 

In  MDTOOL  3.05  we  have  identified  the  following  bugs  and  technical  limitations; 

( 1 )  The  UNIX  VI  editor  is  not  adequate  for  general  use  as  a  word  processor.  Its 
commands  are  cryptic,  cumbersome  and  difficult  to  memorize. 

(2)  There  are  no  provisions  for  aircraft  weapon  sensor  and  weapon  load  specifications. 

(3)  Only  single  seat  aircraft  are  accomnKxiated,  limiting  usage.  (Work-arounds  are 
possible  but  cumbersome  by  creating  event  timelines  for  each  player  in  the  cockpit.) 

(4)  Large  map  areas  (or  linked  map  cells)  are  too  slow  to  work  with  since  MDTOOL 
redraws  or  initializes  the  map  area  after  each  menu  selection. 

(5)  There  is  no  file  name  cited  when  errors  and  memory  dumps  occur,  making  it  difficult 
to  locate,  diagnose,  and  fix  problems. 

(6)  The  user  cannot  create  realistic  special  maneuvers,  e.g.,  pop-ups.  MDTOOL  does 
not  model  these  correctly. 

(7)  Threats  are  not  affiliated  with  a  particular  side.  That  is,  threats  see  everything  as 
"foe"  so  that  aircraft  are  subject  to  attack  by  "friendly  fire". 

(8)  The  algorithms  for  the  holding  pattern  option  are  incorrect. 

(9)  Entering  negative  g  values  is  difficult.  Whereas  "negative  g"  values  arc  intuitively 
thought  of  as  positive  numbers,  MDTOOL  requires  a  negative  number.  If  working  from  an 
existing  menu,  the  negative  sign  already  exists  and  the  numeric  value  can  be  entered.  But  if 
the  sign  in  the  prompt  is  deleted,  it  cannot  be  re-entered. 

(10)  The  6  DOF  aero  model  does  not  work  properly.  (The  program  will  run,  but  the 
resulting  output  aero  parameters  are  incorrect.) 

Overall,  our  criticism  of  the  current  CIPLP  is  that  it  is  labor-intensive  to  use.  The  extent 
of  this  limitation  is  dependent  upon  the  extent  of  the  analysis  being  performed.  If  the 
entire  control/display  suite  is  being  analyzed,  it  is  more  efficient  to  create  the  "*.cccin"  file 
using  the  EDT  Editor  available  on  the  VAXstation  II/GPX  than  by  responding  to  each  of 
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the  prompts  in  CIPLP.  A  major  limitation  leading  to  user  frustration  is  being  unable  to 
abort  from  one  selection  to  return  to  a  previous  menu.  This  may  cause  the  user  to  abort  the 
program  entirely  (CTRL/C)  and  start  from  the  beginning.  There  were,  however,  no  bugs 
found  in  the  CIPLP  version  delivered  in  June  1990. 

For  NMT  we  have  the  following  critical  comments: 

( 1 )  The  mouse  is  ignored  during  string  edit,  which  prohibits  the  user  from  aborting  to  the 
previous  selection. 

(2)  The  program's  prompting  for  prefixes  to  file  names  has  no  meaning  for  the  user  and 
no  apparent  use,  leading  to  confusion.  (Boeing  has  improved  this  feature  in  later 
versions.) 

(3)  There  are  errors  in  the  routine  "Attach  Functions  to  Events."  This  could  only  be 
executed  by  locating  nodes  by  number.  When  NMT  searches  the  treenet  for  the  next 
function,  it  does  not  find  the  associated  function  in  the  event_function  database;  NMT 
clears  the  last  selection  and  the  database  is  reset  at  the  beginning  of  the  file. 

(4)  The  routine  "Initiate  Task  Creation;"  is  too  restrictive  in  requirements  for  the  treenet 
name.  It  will  not  function  unless  "cockpit"  forms  the  first  seven  letters  of  the  name. 

No  bugs  or  technical  limitations  were  found  in  CCC. 

For  our  example  design  problem,  performing  geometric  analysis  (reach  or  vision)  was  not 
a  requirement.  Therefore,  none  of  the  associated  CAT  software  tools  (DLA,  MCOS, 
OAR)  were  used  to  test  design  problem  files.  However,  demonstration  data  provided  by 
Boeing  was  used  to  test  both  reach  and  vision  analysis.  All  programs  were  found  to 
function;  nt  bugs  were  detected.  Limitations  will  be  determined  when  the  software  has 
been  applied  more  widely  to  include  realistic  data. 

We  were  unable  to  run  Pn  because  the  calling  routine  could  not  find  the  appropriate  input 
file.  There  may  be  some  incompatibility  between  CSERIAC-CATs  file-naming 
convention  and  this  version  of  PET.  The  next  version  of  the  CASS  software  tools  resolves 
this  problem  by  generating  the  file  under  the  right  name  in  NMT. 

MSA  was  run  successfully  for  the  example  demonstration  problem  and  appears  to  have  no 
bugs  or  technical  limitations. 
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MPE  software  calculates  workload  statistics  for  each  procedure  in  the  timeline,  performs 
link  analysis,  predicts  task  and  procedure  complexity,  and  provides  procedure  execution 
times.  Procedure  execution  times  are  calculated  from  pre-defined  dwell  and  transit  times 
for  each  channel.  The  inadequacy  or  limitation  that  ensues  from  using  a  theoretical  method 
to  predict  procedure  execution  time  is  that  individual  tasks  of  a  procedure  are  generally  not 
all  performed  sequentially.  Many  tasks  would  be  performed  in  parallel--  that  is, 
simultaneously  or  overlapping.  MPE  attempts  to  accommodate  this  by  calculating  a  time 
root  sum  of  squares  value  (TRSS),  an  artificial  method  of  combining  the  time  required  in 
each  channel  to  get  a  total  time  which  is  somewhere  between  pure  sequential  and  pure 
simultaneous  execution.  Therefore,  the  degree  of  validity  of  the  output  procedure 
execution  times  is  dependent  on  how  accurately  the  dwell  and  transit  times  were  defined, 
and  how  closely  TRSS  was  able  to  simulate  task  overlap.  No  bugs  were  found  in  MPE. 

MTA  output  identifies  the  procedures  (by  number)  that  cause  workload  peaks.  The  reports 
were  difficult  to  interpret  because  the  user  must  cross  reference  other  output  reports  to 
identify  the  actual  procedure  that  is  being  performed  and  to  determine  what  the  "God’s 
Eye"  view  of  the  situation  is-  that  is,  why  the  pilot  is  performing  this  procedure.  There 
was  no  difficulty  in  running  the  program,  however. 

MTP  ran  well  and  we  report  no  bugs  or  limitations. 

In  order  to  run  PLTGGP,  the  DI3000  (Precision  Visuals)  software  must  be  installed  on 
the  VAXstation  II/GPX,  and  the  terminal  print  logicals  must  be  set  up  appropriately. 
DI3(XX)  is  not  installed  at  this  time  so  no  workload  plots  were  obtained.  We  can  therefore 
not  evaluate  this  program  for  bugs  or  limitations. 

FAR  output  was  unobtainable  at  the  time  we  tested  this  program  and  we  cannot  repon  on 
its  performance. 

No  bugs  were  found  in  C-SAINT,  but  the  output  was  not  useful  for  the  demonstration 
example  problem.  C-SAINT  is  best  used  to  determine  an  overall  summary  of  the  amount 
of  time  the  pilot  is  rushed  or  busy,  the  number  of  procedures  the  pilot  is  behind,  and  the 
number  of  procedures  skipped.  However,  it  seems  more  efficient  and  more  direct  to  use 
the  output  of  MPE  and  MTA  to  identify  problem  procedures  that  may  be  amended. 
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As  mentioned,  lATOOL  is  a  Boeing  application  of  the  database  management  system 
Ingres.  During  the  time  the  example  demonstration  problem  was  being  developed,  Ingres 
was  not  fully  accessible  to  the  analyst.  In  addition,  Boeing  engineers  have  since  improved 
the  usability  and  applicability  of  this  software.  For  these  reasons,  and  also  because  of  time 
constraints  and  the  limited  nature  of  our  first  design  problem  which  did  not  require  the  use 
of  LATOOL,  full  exercising  of  Ingres  and  testing  of  the  Boeing  databases  developed  within 
it  will  be  performed  after  delivery  of  the  CAT  ^-2  Interim  version. 

Since  June  1990  but  after  major  testing  of  the  software  in  preparation  for  our 
demonstration,  Boeing  also  upgraded  its  adaptation  of  SUMMET,  the  software  tool  used 
for  decision  making  in  the  Function  Allocation  analysis.  Because  of  time  constraints  and 
the  practicality  of  waiting  to  do  in-depth  testing  until  after  receipt  of  the  upgraded  version, 
and,  again,  because  our  demonstration  problem  did  not  require  a  trade-off  study, 
SUMMET  was  not  tested  for  limitations.  However,  SUMMET,  like  some  of  the  software 
mentioned  above,  has  been  exercised  with  Boeing  demonstration  data  without  uncovering 
any  bugs. 

In  summary,  it  should  be  noted  that  many  of  the  software  problems  encountered  in  CAT 
P*  1  have  been  addressed  since  delivery  of  that  baseline  version,  and  that  more  concentrated 
testing  and  evaluation  of  the  software  is  expected  during  1991. 
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4. 


KUCQMMEISDATIQNS 


CSERIAC-CAT  has  kept  records  in  all  areas  of  managing  and  implementing  CAT  during 
this  period  of  its  development.  Using  these  records  of  our  experience  with  CAT,  we 
exp)ect  to  be  able  to  make  an  increasing  number  of  recommendations  for  future  management 
of  the  program  and  for  the  transfer  of  this  technology  to  the  cockpit  design  community. 

4.1.  Equipment  Needs:  HW  &  SW 

4.1.1.  Hardware 

With  the  current  hardware  configuration  of  the  Silicon  Graphics  Iris  4D/50G,  the  DEC 
VAXstation  II/GPX  and  the  DEC  VAX  8250,  evolution  of  the  CSERIAC  CAT  facility  into 
a  training  and  analysis  center  for  CAT  tools  supporting  more  than  a  few  problems 
concurrently  would  require  at  least  two  hardware  upgrades. 

•  One  recommendation  is  to  increase  disk  capacity  for  the  Silicon  Graphics  IRIS 
workstation. 

•  The  second  is  to  improve  tape  backup  capacity  for  the  VAX  systems. 

•  Additionally,  one  should  address  the  issue  of  memory  capacity  for  the  VAX  8250. 

For  CAT  usage  as  it  exists  now,  the  current  Silicon  Graphics  IRIS  4D/50G  system  is 
adequate  for  the  current  MDTOOL  package  applied  to  a  single  analysis.  Where  the  system 
proves  inadequate  is  in  hosting  multiple  analyses  with  more  users  working  different 
problems  (e.g.  fighter,  cargo,  and  bomber  cockpits  all  being  analyzed).  The  basic 
problem,  as  noted  above,  is  inadequate  disk  space  on  the  current  workstation.  The 
workstation  is  essentially  a  stand  alone  configuration.  It  communicates  with  the  VAXes 
over  the  network  but  it  is  not  practical  to  store  files  and  directories  on  the  Silicon  Graphics 
except  on  the  local  disk.  Disks  for  the  4D  series  come  in  380  Mbyte,  780  Mbyte,  and  1.2 
Gbyte  sizes  (retail  prices  approximately  $3500,  $5000,  and  $7500,  respectively). 

•  In  order  to  support  a  group  of  MDTOOL  users  on  the  current  4D/50G  system,  disk 
storage  must  be  added.  If  disk  size  is  increased  for  the  workstation  by  adding  one  of 
the  larger  capacity  disk  drives  (780  Mbyte  or  more),  the  existing  380  Mbyte  disk  could 
be  used  on  another  Armstrong  Laboratory  IRIS  4D  workstation. 
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•  However,  we  recommend  considering  a  broader  perspective.  The  general  problem  of 
impending  obsolescence  should  be  addressed,  particularly  for  the  IRIS. 

The  4D/50G  system  is  a  RISC  based  cpu  with  380  Mbyte  SCSI  disk  and  a  "low  density" 
cartridge  tape  graphics  workstation.  Silicon  Graphics  no  longer  includes  this  model  in  their 
current  product  line  but  has  retained  the  single  RISC  based  cpu  systems  as  a  personal  IRIS 
set  of  products  (4D/20, 4D/25  and  4D/35)  and  a  line  of  parallel  processing  systems  known 
as  "power  series"  products  (4D/310  and  up).  They  are  currently  offering  an  upgrade 
option  to  customers  wishing  to  convert  obsolete  4D  systems  to  the  low  end  of  the  power 
series  (4D/310).  This  offer  expires  June  30, 1991.  WRDC  has  a  requirements  contract  in 
place  to  take  advantage  of  this  upgrade  for  the  Silicon  Graphics  systems  at  WPAFB. 

If  funding  is  available  there  are  practical  reasons  for  such  an  upgrade.  The  older  systems 
will  continue  to  become  more  expensive  to  maintain  and  eventually  become  incompatible 
and  unsupported  by  Silicon  Graphics.  The  current  4D/50G  system  is  not  part  of  the 
incrementally  upgradable  line  of  the  SG  power  series  which  can  be  easily  upgraded  by 
adding  cpus,  memory,  etc.  as  more  powerful,  faster  machines  are  required  for  new 
applications.  (All  models  in  the  power  series  are  basically  the  same  with  just  more 
processors  and/or  memory.)  Silicon  Graphics  is  currently  improving  the  power  series  with 
firmware,  hardware,  and  software  as  part  of  normally  provided  system  maintenance.  Other 
4D  systems  are  essentially  frozen  at  their  current  capacities. 

The  current  CAT  software  also  requires  VAX  computers,  and  some  of  it  specifically 
requires  a  VAX  GPX  graphics  workstation.  It  is  possible  (but  not  practical  in  our 
environment)  to  have  large  capacity  disk  storage  on  the  DEC  workstation,  so  a  second 
VAX  system  at  another  location  must  be  networked  or  clustered  with  it.  Disk  capacity 
must  be  large  enough  to  conduct  separate  analyses  and  the  system  must  contain  enough 
memory  to  accommodate  applications  and  third  party  (commercial)  software.  The  current 
VAX  8250  contains  only  8  Mbytes  of  memory  and  this  is  the  lower  limit  for  critical 
software  such  as  the  current  Ingres  database  management  system.  In  fact,  if  the  Ingres 
software  is  updated  we  may  not  be  able  to  host  the  new  version  without  additional 
memory. 

A  major  activity  on  the  CAT  VAXes  is  user  and  system  backups.  The  amount  of  software 
on  the  system  is  large  and,  as  users  are  added,  a  significant  amount  of  the  remaining  disk 
capacity  will  be  used  up.  Eventually,  backing  up  the  system  on  the  TU81  tape  drive  of  the 
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VAX  8250  may  take  8  hours  or  more.  This  is  not  efficient  and  a  better  backup  system  is 
recommended,  particularly  to  suppon  CAT  training.  For  the  current  VAX  system,  the 
controller  and  drive  for  an  8  mm  backup  would  allow  for  fewer  backup  tapes  and  fewer 
hands-on  backup  procedures. 

Again,  one  must  consider  the  cost  of  obsolescence.  DEC  bases  hardware  and  software 
maintenance  price  structure  on  the  original  retail  value  of  the  hardware.  Yearly  inflation 
increases  maintenance  costs.  This  creates  a  peculiar  situation.  As  the  hardware  evolves 
and  models  in  the  product  line  are  replaced  with  better  and  faster  machines,  it  can  become 
impractical  to  continue  to  run,  or  to  upgrade,  older  DEC  computers  Furthermore,  Digital 
equipment  requires  that  brand  new  licenses  be  obtained  for  all  soli  ware  on  upgraded 
models  of  their  computers.  It  should  also  be  noted  that  third  party  software  vendors  follow 
DEC'S  lead  in  their  pricing  policies  for  yearly  maintenance. 

•  It  may  be  technically  and  financially  feasible  to  replace  the  VAX  8250  with  a 
VAXstation  III  system. 

The  software  and  hardware  maintenance  costs  and  license  fees  are  less  for  the  lower-end 
cpu  and  large  capacity  disk  storage  would  still  be  possible.  Performance  of  a  lower-end 
cpu  is  rapidly  downgraded  if  too  many  interactive  or  batch  sessions  are  required,  but  since, 
currently,  many  users  do  not  need  to  be  logged  in  at  the  saine  time,  this  might  not  be  a 
problem.  CSERIAC  will  investigate  the  relative  merits  of  substituting  a  newer,  lower-end 
VAX  for  the  VAX  8250. 

•  If  the  current  configuration  is  maintained,  however,  we  recommend  at  least  more 
memory  and  an  improved  back-up  system  for  the  VAX  8250. 

4.1.2.  Software 

In  addition  to  maintaining  appropriate  versions  of  the  operating  systems  software, 
commercial  products  like  Ingres,  MDTOOL  and  I-DEAS,  and  the  Boeing-developed  CAT 
tools,  CSERIAC  strongly  recommends  the  purchase  of  two  types  of  software  products 
which  are  not  currently  part  of  CAT,  improvement  of  the  Boeing  support  software  (besides 
the  programs  themselves),  and  consideration  of  additional  system  tools.  Discussed  below 
are  Computer-Aided  Software  Engineering  (CASE)  tools,  and  MCAD  libraries  or  standard 
tools  for  the  creation  or  modification  of  cockpit  geometries.  Improvement  of  the  Boeing- 
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developed  databases  and  other  Boeing  input  files  would  also  add  to  CSERIAC  capability, 
and  the  purchase  of  some  less-critical,  but  very  useful  general  system  management  tools  is 
also  recommended. 

A  set  of  appropriate  CASE  tools  would  help  CSERIAC  fulfill  its  aim  in  developing  as  a 
training  and  analysis  center  for  CAT  in  a  multi-user,  multi-project  environment.  Key 
questions  in  the  suppon  of  multiple  projects  is  how  much  of  each  set  of  files  must  be 
duplicated  for  each  user  account  and  which  files  are  better  left  in  common  areas  accessed  by 
all  users.  Furthermore,  some  projects  will  require  additions  and  nnodifications  to  data 
bases  used  to  describe  or  represent  parameters  of  the  aircraft  and  human  performance.  For 
those,  it  is  necessary  to  provide  local  or  user  specific  copies  of  some  files.  That  is,  data 
appropriate  for  fighter  missions  is  not  necessarily  the  same  as  that  for  refueling  missions. 

Similarly,  mission,  aircraft,  and  analysis  specific  data  within  a  single  project  or  belonging 
to  unrelated  projects  must  be  controlled  and  managed.  CASE  can  greatly  ease  the  burden 
of  version  control  and  help  to  prevent  confusion  and  mistakes. 

For  VAX  systems  DEC  markets  a  product  called  VAXset  which  includes  LSE/SCA 
(Language-Sensitive  Editor/Source  Code  Analyser),  CMS  (Code  Management  System), 
MMS  (Module  Management  System),  and  other  elements.  On  the  Silicon  Graphics  system 
there  is  the  RCS  (Revision  Control  System)  and  the  make  utility.  These  systems  perform 
audit  histories  of  changes,  support  multiple  versions  for  text,  source  code  and  data,  and 
also  perform  various  library  functions. 

LSE/SCA  is  present  on  the  CSERIAC-CAT  VAXes  but  the  most  useful  of  the  other  CASE 
tools  (CMS  and  MMS)  are  not.  Without  these,  a  number  of  records  must  be  maintained 
manually  (i.e.  with  editors)  which  identify  the  contents  and  purposes  of  each  of  the  various 
versions  of  files  created  on  the  system.  It  takes  a  good  deal  of  diligence  to  prevent 
confusion,  mixups  and  other  problems.  CASE  tools  automatically  keep  track  of  a  lot  of 
useful  information  in  such  an  environment.  For  the  CSERIAC-CAT  Silicon  Graphics  IRIS 
workstation,  the  two  most  useful  CASE  tools  are  RCS  and  the  make  utility,  which  we  do 
have,  and  we  will  implement  additional  version  control  by  writing  shell  scripts. 

•  Continued  use  of  these  products  is  recommended. 
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•  In  support  of  CSERIACs  growing  capability  as  a  training  and  analysis  center  for  CAT, 
we  recommend  adding  other  tools  from  the  DEC  CASE  package,  in  particular  CMS  and 
MMS. 

While  a  fair  amount  of  experience  with  the  CAT  software  tools  has  been  gained  at 
CSERIAC,  there  is  a  serious  lack  of  general  MCAD  tools  and  data  files  to  support  the 
MCAD  programs.  Methods  are  being  devised  for  the  addition  of  information  and 
descriptions  to  the  CAT  data  bases  for  missions,  human  factors,  evaluation  criteria,  etc. 

But  no  part  of  the  CAT  software  directly  supports  these  data  enhancements  and  no 
programs,  tools  or  documentation  currently  exist  to  manipulate  the  basic  information  on 
which  all  the  CAT  analyses  are  based. 

As  configured,  the  CAT  software  is  lacking  straightforward  or  efficient  means  for  the 
creation  or  modification  of  cockpit  geometries.  To  date,  all  analyses  have  used  previously 
created  cockpit  geometry  files.  The  CIPLP  program  allows  manual  entry  of  geometric 
elements  of  a  cockpit  one  point  at  a  time  and  the  I-DEAS  CAD/CAM  system  can  be  used  to 
manipulate  geometric  elements.  But  no  specific  library  of  cockpit  parts  such  as  displays 
and  controls  has  yet  been  provided,  and  no  procedures  to  manipulate  and  assemble  parts 
are  currently  part  of  the  CAT  software.  Assembling  a  cockpit  from  scratch  is  a  major 
undertaking  which  is  not  well-supported  by  current  CAT  software. 

Furthermore,  there  are  no  documented  guidelines  and  no  established  procedures  for 
modifying  existing  parts  of  the  cockpit  geometry.  This  would  be  simpler  than  designing  a 
complete  new  cockpit,  but  issues  of  data  formats  and  the  availability  of  data  files  must  still 
be  addressed  and  procedures  for  conversion  of  CAD  data  must  be  developed. 

And  finally,  there  is  the  problem  of  supporting  a  realistic  iterative  design  process.  Analysis 
using  the  CAT  tools  has  been  demonstrated  in  a  "single-pass"  run  of  a  posed  problem,  but 
a  designer  is  likely  to  need  a  matrix  of  results  for  a  range  of  some  design  factor,  or  want  to 
iterate  a  design  through  multiple  passes,  altering  the  design  on  each  pass  based  on  the 
results  of  analysis.  This  is  difficult  with  the  current  software  and  the  simplest  method  at 
present  is  to  edit  the  geometry  file  directly,  that  is,  by  altering  the  list  of  numbers 
representing  coordinates  and  identifiers. 
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•  We  therefore  strongly  recommend  acquiring  interfaces  to  manipulate  the  cockpit 
geometry  graphically  in  suppon  of  the  CAT  analysis  tools,  and  the  establishment  of  a 
robust  library  of  CAD  shapes  and  other  CAD  data  files. 

•  We  note  also,  as  above,  the  need  for  enhancing  the  other  (Boeing-developed) 
databases  that  interact  with  the  CAT  tools  (e.g.,  event,  event_function, 
function_procedure).  Better  definition  of  the  data  requirements,  and  better  descriptions 
of  their  structure  and  functions  are  needed.  Also  lacking  are  documented  procedures 
for  updating  and  maintaining  these  databases,  and  explanations  about  what  happens 
when  elements  of  the  database  are  edited. 

•  Other  Boeing-developed  input  files  such  as  those  involved  in  workload 
prediction  and  cockpit  configuration  control  also  need  review  and  improvement. 

During  preparation  of  the  demonstration  design  problem,  for  example,  some  of  the 
output  from  the  workload  analysis  created  concern  for  the  validity  of  the  input  data  and 
the  algorithms  used. 

•  Besides  the  acquisition  of  CASE  and  MCAD  software  and  improvement  of  the 
databases  and  other  input  files,  we  recommend  acquiring  some  general  system 
management  tools.  SPM  (System  Performance  Management),  Disk  Defragmentors, 
and,  to  a  lesser  degree,  RSM  (Remote  System  Manager)  are  those  worthy  of 
consideration. 

Additionally,  we  note  that  although  specific  CAT  software  tools  were  developed  to  support 
specific  procedures  in  the  C/  T  Methodology,  implementation  of  the  Methodology  was  not 
meant  to  be  limited  only  to  the  use  of  those  tools. 

•  It  is  recommended  that  other  software  sources  be  sought  for  possible  adaptation  to  the 
CAT  process.  Software  may  exist  that  is  easier  to  use,  more  powerful,  or  lower  in 
cost,  thus  allowing  for  growth  and  flexibility  as  technology  grows. 

4.2.  Technical  Personnel  and  Task  Management 

Because  of  the  late  delivery  of  ([L^T  equipment  and  software  and  the  protracted  period  of 
assembling  appropriate  personnel,  the  biggest  priority  at  the  beginning  of  1990  was  task 
start-up--  developing  a  cohesive  and  efficient  CSERIAC-CAT  team,  configuring  the 
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equipment  in  a  productive  work  environment,  implementing  management  procedures  and 
configuration  control,  familiarizing  key  technical  personnel  with  CAT  tools  and  objectives, 
establishing  liaison  and  working  relationships  with  Boeing  and  with  the  CAT  ADPO,  and, 
of  course,  completing  the  requirements  of  the  contract  itself,  especially  with  respect  to 
deliverables.  Having  accomplished  all  of  this,  we  see  the  next  contract  period  as  one  in 
which  priority  shifts  from  start-up  to  full-scale  development  of  CSERIAC-CAT 
capabilities.  As  such,  we  see  the  need  to  maintain  and  to  continue  increasing 
accomplishments  in  the  above  areas  while  extending  technical  capabilities  specific  to  the 
CAT  Methodology  and  the  use  of  the  CAT  tools. 

•  We  recommend  a  continuing  "core"  CSERIAC-CAT  team  of  individuals  who  would 
perform  the  principal  roles  of  Task  Manager,  Systems  Manager,  and  Cockpit  Design 
Engineer.  All  three  will  support  analysis  activities  for  user  agencies. 

•  In  addition,  this  team  would  rely,  as  required,  on  other  CSERIAC  staff  for  support  in 
administration  and  management,  development  and  implementation  of  training  courses 
and  workshops,  the  writing  of  manuals  and  other  documentation,  and  the  development 
of  CAT  tools  or  CAT  management  support  databases. 

•  We  further  recommend  that  subject  matter  experts  in  operations  and  tactics,  and 
especially  tho.se  with  piloting  experience  (both  fighter  and  transport)  be  identified  as 
potential  resources. 

4.3.  Technology  Transfer  and  Training 

We  note  that  transferring  CAT  technology  to  the  cockpit  design  community  encompasses 
issues  of  general  demonstrations  in  CAT  capabilities,  training  in  its  use,  in-depth  and 
specific  demonstrations  given  in  conjunction  with  analyses  support,  and  promotion  and 
marketing  of  the  technology.  While  recognizing  that  these  issues  merit  individual  attention 
and  have  been—  and  will  continue  to  be—  addressed  individually,  we  view  them  primarily 
within  the  context  of  technology  transfer. 

Although  demonstrations  were  given  throughout  the  year  to  government  and  potential 
users,  they  were  limited  in  content  to  the  current  version  of  the  CAT  Methodology  and 
software.  Besides  improving  content,  developing  the  demonstrations  into  two  distinct 
types  would  be  useful. 


34 


•  Development  of  a  general  overview  demonstration  for  management  is  recommended 
that  would  give  a  brief  description  of  the  CAT  Methodology  and  tools  and  would 
summarize  their  capabilities. 

•  A  second  type  of  demonstration  for  users  would  give  more  details  by  presenting  an 
example  application  of  the  Methodology  and  software  within  the  context  of  a  real 
design  problem. 

By  continuing  and  expanding  CSERIACs  role  in  analyses  support,  the  overall 
objectives  of  technology  transfer  as  well  as  training  and  promotion  will  be  served.  The  old 
maxim  that  "satisfied  customers  are  the  best  means  of  advertising"  is  true. 

•  We  recommend  enhancing  team  expertise  in  CAT  and  cockpit  design,  and  making 
much  more  use  of  CSERIAC  (and  UDRI)  resources  in  human  factors  engineering,  so 
that  we  can  promote  and  carry  out  our  role  as  expert  consultants  in  the  design  process. 

The  Procedures  Notebook  that  was  created  for  managing  and  implementing  the 
demonstration  design  problem  paralleled  and  complemented  the  procedures  of  the  DenVVal 
Phase  of  the  Weapon  Systems  Design  Process  and  the  analysis  stage  of  the  CAT 
Methodology  and  was  instrumental  in  completing  the  design  problem.  [5.9.,  6.2.] 

•  It  is  recommended  that  a  second  generation  Procedures  Notebook  be  developed  that 
corresponds  to  the  Designer's  Electronic  Notebook  (DEN)  currently  under  development 
by  Boeing.  By  expanding  the  Procedures  Notebook  and  its  use,  better  manageability 
and  traceability  will  be  obtained. 

Besides  the  promotion  and  marketing  advantages  gained  by  demonstrating  CAT  to  potential 
users  and  by  using  it  to  help  analyze  real  world  design  problems,  advertising  in  trade 
magazines  and  journals,  writing  technical  articles  for  publication  in  the  GATEWAY  and 
other  periodicals,  presenting  papers  at  technical  conferences,  and  featuring  CAT  at  trade 
shows  and  symposia  are  all  possibilities  within  the  scope  of  CSERIAC  experience  and 
capabilities. 
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•  We  therefore  recommend  establishing  a  regular  program  of  promotion  and 
marketing  once  the  final  CAT  release  is  functional  and  adequate  documentation  has 
been  developed. 

Formal  workshops  in  the  use  of  CAT  have  already  been  identified  by  the  CAT  ADPO  as 
important  avenues  of  technology  transfer.  Again,  development  of  adequate  documentation 
in  the  form  of  user's  manuals  and/or  procedures  notebooks  is  an  impcHtant  prerequisite. 
We  have  noted  the  possibility  of  different  types  of  workshops  in  our  Workshop  Plan 
[5.8.],  and  we  see  the  possibility  of  distinguishing  types  of  woricshops  differently  later  on 
when  CAT  is  fully  developed.  General  workshops  offered  periodically  to  the  tx’oad 
community  of  crew  station  design  engineers  is  one  obvious  category.  Specialized 
workshops  offered  on-site  to  companies  or  organizations  embarking  on  major  design 
projects  or  groups  of  projects  is  another  possible  category.  We  see  both  types  as  major 
efforts  on  CSERIACs  part. 

•  We  recommend  emphasis  on  periodic  workshops  as  major  avenues  of  technology 
transfer  once  the  final  CAT  version  is  operational. 
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5. 


5.1.  Statement  of  Work,  Contract  DLA900-88-D-0393,  5  July  1989;  issued  to  the 
University  of  Dayton,  by  Defense  Electronics  Supply  Center,  Contract  Specialist: 
PSC/  S.  Robbins. 

5.2.  Inventories  (T.  Abrams  to  CAT  ADPO),  1 .  CAT  Software  Inventory,  22 
February  1990;  2.  CAT  Inventories,  Hardware  and  Documentation,  30  March 
1990. 

5.3.  Evaluation  of  [Boeing]  CAT  Training  (CSERIAC  Program  Office  to  Phil 
Kulwicki,  AAMRT7HEX-CAT),  22  December  1990. 

5.4.  Quarterly  Reports,  Technical  and  Configuration  Control  (UDRI CSERIAC- 
CAT  to  AAMRL/HEX-CAT  Program  Office),  1.  July- September  1989;  2. 
October-December  1989;  3.  January-March  1990;  4.  April-June  1990;  5.  July- 
September  1990;  6.  October-December  1990. 

5.5.  Associate  Contractor  Agreement  Between  The  University  of  Dayton 
and  The  Boeing  Company  Acting  Through  Boeing  Military 
Airplanes,  signed  by  D.E.  Bjomson  (Boeing),  20  November  1990,  and  R.P. 
Boehmer  (Univ  of  Dayton),  27  November  1990. 

5.6.  Configuration  Control  Plan  (CSERIAC-CAT  to  AAMRL/HEX-CAT 
Program  Office),  20  November  1990. 

5.7.  "Demonstration  of  CAT  Software  Tool  Capability  and  CSERIAC- 
CAT  Proficiency  Using  an  Engineering  Cockpit  Design  Problem", 

C.  Martin,  T.  Abrams,  C.  Orr,  December  1990. 

5.8.  Workshop  Plan  (CSERIAC-CAT  to  AAMRL/HEX-CAT  Program  Office), 

20  December  1990. 

5.9.  Procedures  (Project  Name),  C.  Martin,  December  1990. 
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Configuraiion  Control  Plan.  20  Nov  1990 


6.  AEPENBICES 

6.1.  Configuration  Control  Plan 

(Original  in  menx)  form,  CSERIAC  letterhead) 


To:  AAMRL/HEX-CAT  Program  Office  20  November  1990 

Lt./Col.  R.  Collins,  Mr.  P.  Kulwicki 

From:  CSERIAC-CAT 
T.  Abrams,  C.  Orr 


CONFIGURATION  CONTROL  PLAN 

Contents: 

1 .  Introduction  and  Overview 

2 .  Establishment  of  Baseline  Configuration 

3.  Inventories  of  Configuration  Items 

4.  Control  Method:  Configuration  Control  Database 

5 .  Evaluation 


1 .  Introduction  and  Overview 

According  to  MIL-STD-480B,  configuration  control  has  to  do  with  changes--  proposal, 
justification,  evaluation,  coordination,  approval  or  disapproval  and  implementation  thereof, 
to  approved  baselines.  Configuration  control  of  the  CAT  hardware,  software  and 
documentation  at  CSERIAC  must  be  established,  however,  with  the  objectives,  time  frame, 
and  relationships  (or  dependencies)  of  this  special  task  in  mind.  For  this  contract  period, 
CSERIAC  is  acting  as  a  beta  site  for  the  evaluation  and  testing  of  software  under 
development.  All  software  and  hardware  acquired  by  CSERIAC  and  incorporated  into  the 
CAT  system  comes  from  the  prime  developer.  The  Boeing  Company  Milit^  Airplanes 
Division,  through  the  CAT  ADPO.  CSERIAC,  therefore,  must  play  a  predominantly 
reactive  role-  to  incorporate,  test,  keep  track  of,  and  evaluate  what  we  are  given.  During 
the  period  of  this  specif  task,  no  significant  hardware  or  software  changes  will  be  initial^ 
by  CSERIAC. 

Current  hardware  may  be  classified  as  belonging  to  or  interfacing  with  three  (sub)systems- 
a  DEC  VAX  8250  computer  (called  MERLIN),  a  DEC  GPX  graphics  woricstation  (called 
WREN),  and  a  Silicon  Graphics  IRIS  graphics  workstation  (called  CATBIRD). 

Current  software  may  be  classified  in  two  dimensions—  the  first  as  "belonging  to"  one  of 
the  three  hardware  systems  listed  above,  and  the  second  as  either  (1)  systems  software 
including  operating  systems,  editors,  programming  languages,  etc.;  (2)  interface  software 
for  networking,  clustering,  and/or  other  communications;  (3)  third  party  applications  such 
as  Ingres,  I-DEAS,  and  MDTOOL;  or  (4)  Boeing-develop^  applications  or  tools. 
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2 .  Establishment  of  Baseline  Configuration 
2.1.  Hardware 

The  baseline  configuration  for  hardware  was  established  early  in  1990,  with  equipment 
included  in  the  Early  DCADS  Delivery.  Because  of  limited  disk  space,  and  to  suit  the  CAT 
tools'  requirements  for  transferring  files  between  the  IRIS  and  VAX  equipment,  MERLIN 
and  WREN  were  clustered,  and  the  two  workstations  (WREN  and  CA'TBIRD)  were 
networked.  Besides  the  primary  terminals  on  each  workstation,  another  terminal  is 
connected  through  a  terminal  server  to  MERLIN,  WREN,  and  two  other  AAMRL  VAX 
computers,  FALCON  and  EAGLE. 

Baseline  hardware  configuration  will  provide  color  graphics  printing  capability  from  either 
CATBIRD  or  WREN  by  means  of  one  Tektronix  printer.  (Another  contractor  has 
responsibility  for  providing  the  necessary  cable.)  Additionally,  an  LN03  printer  is 
available  to  any  terminal  through  MERLIN. 

Specific  descriptions  for  each  hardware  component—  manufacturers,  model  numbers, 
licensing/support  information,  etc.—  exist  now  as  hard  copy  lists  and  will  be  available  from 
the  configuration  control  database  once  it  is  populated.  (The  database,  Catcon,  is  described 
below  in  Section  4). 

2.2  Software 

Baseline  software  configuration  centers  on  the  June  1990  version  of  the  CAT  Analysis 
Software  (dubbed  CAT  6-1),  MDTOOL  version  3.05, 1-DEAS  4.3,  Ingres  6.2,  and  the 
VAXA^MS  5.3- 1  and  IRK  3.2  operating  systems.  Specific  descriptions  for  each 
software  component,  likewise,  exist  now  as  hard  copy  lists  and  will  be  available  from  the 
configuration  control  database,  Catcon. 

2.3  Documentation 

CSERIAC  has  no  technical  documentation  as  yet  that  is  specific  to  the  current  (6-1) 
Boeing-developed  CAT  tools,  though  a  few  early  User's  Manuals  (1987,  1988)  are  on 
hand  and  do  provide  some  insight  into  the  development  strategy  and  objectives.  These 
publications,  along  with  all  documentation  for  systems,  interface  or  third  party  applications 
software,  and  all  hardware  documentation,  have  been  catalogued  on  inventory  lists  and  are 
kept  in  the  CSERIAC  CAT  Room  library.  Each  piece  of  documentation  will  be  represented 
in  Catcon,  in  the  record  for  the  hardware  or  software  item  to  which  that  documentation 
relates.  Tliis  library  system  may  be  developed  further  if  necessary,  by  tagging  each  copy 
of  each  item  with  decimal  codes,  e.g. 


3.  Inventories  of  Configuration  Items 

Inventories  have  been  prepared  for  all  hardware  and  software  items,  and  for  all 
documentation  (Feb  1990,  Mar  1990).  The  data  in  these  inventories  will  be  updated  and 
entered  into  Catcon. 


4.  Control  Method:  Configuration  Control  Database 

The  heart  of  CSERIAC's  configuration  control  plan  for  CAT  hardware,  software  and 
documentation  is  Catcon,  a  Macintosh  database  using  the  FoxBASE-^/Mac  database 
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management  system.  FoxBASE  is  a  current  leader  in  microcomputer  database  management 
systems,  particularly  in  terms  of  speed,  flexibility,  and  the  capability  of  handling  large 
amounts  of  text-type  data.  It  has  the  attractive  feanire  of  being  produced  in  both  Mac  and 
PC  versions,  and  (with  appropriate  hardware  and  software  suppon)  a  FoxBASE  database 
can  be  accessed  from  both  Macs  and  PCs  networked  together,  if  that  is  desirable. 
CSERIAC  currendy  owns  the  multi-user  Mac  version  which  can  be  used  by  individual 
Macintosh  computers  or  by  a  network  of  Macintoshes. 

The  first  version  of  the  database  schema  has  been  designed  and  installed.  There  are 
twenty-two  fields,  described  below.  Populadon  of  the  database  (entering  the  data 
described  in  sections  2  and  3  above)  will  take  place  during  the  next  support  period  and  is 
expected  to  be  complete  by  mid  1991. 


CSERIAC  Configuration  Control  Database,  Catcon 


Field  Name 

Data  Type 

Explanation  of  Contents 

1. 

recno 

numeric 

record  number,  the  unique  record  key 

2. 

curr 

logical 

a  "yes"  or  "no"  condition  to  indicate  "current" 
or  "not  current,"  respectively 

3. 

name 

character 

full  name  of  unit  (RA-81,  IRIS-4D,  MDTool) 

4. 

model 

character 

model  or  version  number 

5. 

functn 

character 

functional  description  (Disk  Drive,  Graphics 
Workstation  CPU,  DBMS,  eg) 

6. 

mfgr 

character 

name  of  manufacturer  (Digital  Equipment 
Corp,  Silicon  Graphics,  Merit  Technology, 
eg) 

7. 

mfgrcon 

character 

manufacturer's  POC,  address  and  phone 
number 

8. 

mfgid 

character 

manufacturer’s  serial  or  registration  number 

9. 

govid 

character 

government  identification  or  code 

10. 

swtyp 

character 

software  type  (System,  Commercial 
Application  Program,  Special  Development, 
eg)  (only  for  records  concerning  software) 

11. 

hwsuppi 

character 

hardware  supplies:  complete  names  of  all 
needed.  \o  secondary  supplies  or 

materials  such  as  tape  cartridges,  cables,  print 
wheels,  etc.  (only  for  records  concerning 
hardware) 

12. 

daterec 

date 

date  received 
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13.  dateon 

date 

14.  dateoff 

date 

15.  pendson 

character 

16.  pendents  character 


17.  spfeat 


memo 


18.  instal 


memo 


19.  othrdoc  memo 


20.  licenscurr  memo 


21.  iicenshist  memo 

22.  failhist  memo 


E2^planatiflg  of  Cgnisnts 

date  installed 

date  removed  (for  items  where  curr=yes,  this 
field  should  be  blank) 


"depends  on"...  the  names  of  other  primary 
pieces  (of  HW  or  SW)  necessary  to  make  this 
piece  (of  HW  or  SW)  functional 


"dependents"...  the  names  of  other  primary 
pieces  (of  HW  or  SW)  which  depend  on  this 
piece  to  make  them  functional 

special  features,  refers  to  manufacturer- 
installed  options,  such  as  internal  hard  drive 
size,  RAM  size,  etc. 

distribution  information  (installation 
instmcdons,  distribution  tapes  or  disks,  etc.); 
name,  identification  codes  (if  any),  and 
location  of 

relevant  documentation,  other  than 
distribution  instructions:  name,  identification 
codes  (if  any),  location  of 

current  licensing  or  support  agreement 
information:  name  of  owner,  date  purchased, 
cost,  time  period  valid,  expiration  date,  terms 
(if  relevant),  POC  for  extending,  etc. 

licensing  or  support  agreement  history,  same 
information  as  above 

failure  and  resolution  histories;  date  and 
problem,  how  it  was  resolved,  for  each 
incident 


Each  record  in  the  database  will  represent  a  unique  piece  of  hardware  or  software, 
excluding  duplicates  for  software  items.  Once  populated,  the  database  will  be  up^ted 
whenever  new  items  are  received  by  CSERIAC  or  changes  to  the  configuration  occur.  The 
CSERIAC-CAT  Task  Manager  and  Systems  Manager  i^l  share  responsibility  for 
maintaining  the  database  and  keeping  it  current.  A  comprehensive  and  concise  User’s 
Manual  for  Catcon  will  be  produced  after  the  database  has  been  populated  and  tested 
(probably  during  the  second  half  of  1991).  Likewise,  output  forms  will  be  designed  to 
user  specifications  so  that  printouts  supplying  particular  information  or  a  particular  aspect 
of  the  data  can  be  produced  quickly.  The  design  of  the  database  is  amenable  to  change, 
should  use  of  this  prototype  indicate  the  need  for  new  types  of  information  and/or  new 
fields. 
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The  current  database  design  (that  is,  the  fields  and  definitions  of  their  content)  and  some 
examples  of  selecting  records  sharing  particular  data  entries  indicate  that  configuration 
control  can  be  maintained  easily.  It  will  be  possible  at  any  time  to  produce  a  printout  that 
describes  the  current  hardware  or  software  configuration,  or  both,  by  selecting  those 
records  that  have  the  field  curr  filled  with  "yes."  Or,  for  example,  in  tending  to  licensing 
needs,  all  items  distributed  by  a  particular  manufacturer  and  in  current  use  may  be  select^ 
via  the  fields  cunr  and  mfgr  and  then  a  listing  of  those  items,  with  whatever  information  is 
necessa’-7,  can  be  printed  out. 

During  the  next  contract/support  period,  two  other  "files"  (or  adjunct  databases)  will  be 
designed  and  implemented  as  special  aids  for  the  Systems  Manager.  One  will  contain  a 
schedule  and  record  of  system  backups,  and  one  will  keep  track  of  user  accounts  and  user 
files,  including  backups.  Backup  schedules  and  procedures  will  be  determined  according 
to  available  hardware  and  to  ne^  as  use  of  the  CAT  tools  increases,  and  these  schedules 
and  procedures  will  be  available  for  reference. 

5 .  Evaluation 

An  important  element  among  the  objectives  of  this  special  task  is  evaluation  of  the 
configuration  items.  Although  this  means  primarily  with  regard  to  the  functionality  of  the 
CAT  software,  CSERIAC-CAT  expects  also  to  provide  evaluation  and  recommendation 
with  regard  to  the  configuration  itself  With  increased  use,  data  will  be  collected  on  the 
accessibility  and  human  factors  aspects  of  both  hardware  and  software  configuration.  The 
ease  of  transferring  files,  the  need  for  on-line  directives  and  messages  or  better  menus,  the 
relative  merits  of  one  workstation  over  another  (including  reliability  and  frequency-of- 
repair,  for  example)  are  a  few  of  the  areas  for  which  data  will  be  gathered. 
Recommendations  for  reconfiguring  the  systems,  for  the  purchase  of  different  or  additional 
hardware  or  software  support  packages  (editors,  compilers,  communications  and  file 
transfer  protocols,  etc.)  will  be  made  as  appropriate. 


Copies: 

Maj.  P.  Irish 
D.  Stafford 
L.  Howell 
C.  Martin 
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6.2.  Procedures  Notebook  (Template  Form) 


PROCEDURES  NOTEBOOK 
(PROJECT  NAME) 

(AUTHORS) 

(DATE) 


(PERFORMING  ORGANIZATION) 
(PERFORMED  FOR) 
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TOP  LEVEL  FUNCTIONAL  FLOW  BLOCKS  OF  THE  CAT  METHODOLOGY  FOR  THE 
DEM/VAL  PHASE  OF  THE  WSDP  AND  ANALYSIS  PROCESS 


The  purpose  of  the  Demonstration  and  Validation  Phase  is  to  expand  the  definition  of 
candidate  concepts  through  extensive  analyses  of  alternatives  and  to  develop  concepts 
from  functional  baseline  systems  to  the  stage  where  prototype  construction  would  be  possible. 
The  Dem/Val  Phase  will  normally  result  in  a  full,  updated  system  specification  for  the  weapon 
system,  as  well  os  critical  item  development  specifications  for  major  subsystems  and  items  of 
equipment  or  software. 

Key  crew  system  design  decisions  which  should  be  resolved  by  the  end  of  the  Dem/Val 
Phase  include  crew  station  geometry,  identification  of  control  and  display  equipment,  control 
and  display  arrangement,  preliminary  panel  layouts,  preliminary  display  formats  and  control 
logic,  and  escape  and  life  support  preliminary  desigr^s 

The  following  CAT  Methodology  top-level  functional  flow  blocks  were  developed  to  provide 
a  structured  and  quantitative  process  that  would  allow  a  designer  to  match  aircrew  needs  with 
evolving  technologies  within  the  Dem/Val  Phase  of  the  Weapon  Systems  Design  Process 
(WSDP)  and  the  Analysis  Process  of  the  CAT  Methodology.  These  top-level  functional  flows 
are  broken  down  further  into  specific  procedures  and  computer  software  has  been  developed 
to  support  these  procedures. 


DAOl.  Develop  Human  Engineering  Plan 

DA02.  Conduct  Mission  and  System  Analysis 

DA03.  Characterize  Mission 

DA04.  Define  Baseline  Crew  Station 

DAOS.  Generate  Control/Display  Catalog 

DAOS.  Perform  Function  Analysis 

DA07.  Attach  Tasks  to  Procedures 

DA08.  Perform  Procedure  Analysis 

DA09.  Perform  Reach  Analysis 

DAIO.  Perform  Internal  Vision  Analysis 

DA1 1.  Perform  External  Vision  Analysis 

DA  12.  Perform  Workload  Analysis 

DA13.  Perform  Information  Analysis 

DA  14.  Review  Configuration  (Rework  or  Accept) 

DAIS.  Perform  Critical  Task  Analysis 

DA  16.  Review  Go-Ahead  for  Evaluation 

DAI  7.  Perform  Function  Allocation  Analysis 

DA18.  Evaluate  Design  Solution  Candidates 

DA  19.  Define  Control  and  Display  Requirements 

DA20.  Define  Operational  Procedures 

DA21.  Establish  Equipment  Requirements 

DA22.  Document  Human  Engineering  Results 
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DA01.  PROCEDURES  FOR  DEVELOPING  THE  HUMAN  ENGINEERING  PLAN 


DA01.1 


a.  CSERIAC  Support  Capabilities:  Given  a  cockpit  engineering  design  problem, 
CSERIAC  will  determine  what  top-level  procedures  of  the  CAT  methodology  will  be 
implemented  for  obtaining  supporting  analysis,  results,  and  providing 
recommendations. 

b.  Design  Problem  Effort: 


DA01.2 


a.  CSERIAC  Support  Capabilities:  CSERIAC  will  determine  what  operational  experience 
will  be  required  to  support  the  completion  of  the  selected  top-level  tasks. 

b.  Design  Problem  Effort: 


DA01.3 


a.  CSERIAC  Support  Capabilities:  Given  a  proposed  cockpit  design  or  redesign  effort, 
CSERIAC  will  recommend  specific  system  analysis  tasks  required  to  obtain  viable 
results  for  basing  human  engineering  system  design  recommendations. 

b.  Design  Problem  Effort: 


DA014 


a.  CSERIAC  Support  Capabilities:  N/A  to  CSERIAC  support  capabilities. 

b.  Design  Problem  Effort: 


DA01.5 


a.  CSERIAC  Support  Capabilities:  CSERIAC  will  define  the  necessary  procedures  to  be 
developed  for  recommended  design  changes. 

b.  Design  Problem  Effort: 


DA01.6 


a.  CSERIAC  Support  Capabilities:  N/A  to  CSERIAC  support  capabilities. 


b.  Design  Problem  Effort: 
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DA01.7 


Identify  Human  Engineering  Delh/eroble  Products 


a.  CSERIAC  Support  Capabilities:  CSERIAC  will  provide  final  documentation  of  results 
and  cockpit  design  recommendations  of  the  analyses  performed  to  be  included  in 
the  Human  Engineering  Deliverable  Product  documentation. 

b.  Design  Problem  Effort: 

DA01.8  Determine  Level  of  Effort  for  the  Humon  Engineering  Tasks 

a.  CSERIAC  Support  Capabilities:  N/A  to  CSERIAC  suppx>rt  capabilities. 

b.  Design  Problem  Effort: 

DA01.9  DevelQp  Humon  Engiofiefing  Program  Schedule 

a.  CSERIAC  Support  Capabilities:  N/A  to  CSERIAC  support  capabilities. 

b.  Design  Problem  Effort: 

DA01.10  Document  Human  Engineering  Program  Plan 

a.  CSERIAC  Support  Capabilities:  N/A  to  CSERIAC  support  capX3bilities. 

b  Design  Problem  Effort: 
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DA02.PfiC>CEDURES  FOR  CONDUCTION  MISSION  AND  SYSTEM  ANALYSIS 

Tj(planations  and  e;(fimpUs  appear  in  tfiis  section  for  clarification. 


DA02.1  Describe  Mission  and  Aircraft 

a.  CAT  Software  Tool  -  MDTOOL 

b.  Inputs  -  from  subject  matter  experts  with  operational  experience,  human 
engineering  document,  and  Weapon  System  Requirements  document 

c.  Output  -  mission  synopsis  text  file,  ".syn" 

d.  Design  Problem  Input  -  (Document  ad  resources  used  as  inputs  for  descriSing  the  mission 
and  aircraft,  for  e^campCe,  ‘The  mission  scenario  ttfas  obtained  from  (Mr.  John  (Doe 

The  document  reference  is  ‘Tanhfr  JitHonics/Aircreto  CompUment  'Evaluation 
(TAACE),  Volume  III:  (Mission  Scenario,'  TX  *ATl^AL  T%:80-3030,  May  1980,  AD 
A088036.  Additional  sunario  clarification  tvas  obtained  from  Col  'Bob  Cat  (IVPAJ'B). 

e.  Design  Problem  Output  -  Identify  location  of  output  if  it  is  in  paper  format  or  specify  the 
filename  that  tvas  created  while  using  the  CAT  software  tool.  Tor  example,  in  this 
procedure  MDTOOL  is  used  and  the  output  file  created  to  document  the  description  of  the 
mission  and  aircraft  might  be  ‘‘KCI^^-syri 

f.  Design  Problem  %  Complete  -  Determiiu  the  level  of  completion  after  entering  any  new 
data  to  this  procedure  blocfi,  i.e.  100%. 

g.  Design  Problem  Notes  -  This  is  a  good  plau  to  identify  any  bugs  or  limitations  in  the  CAT 
softtvare,  lessons  leanud,  or  peculiarities  of  implementing  this  proudure.  Tor  er^ample:  ‘8 
Apr  91:  'UTiile  editing  with  the  vi  ertitor,  the  user  must  include  a  hard  return  after  each 
Une,  otherwise,  MDTOOL  wid  not  be  able  to  read  the  te^tfde  created." 


m 


DA02.2 


a.  CAT  Software  Tool  -  MDTOOL 

b.  Inputs  -  from  subject  matter  experts  with  operational  experience 

c .  Output  -  documented  information  for  input  into  the  mission  objective  file 

d.  Design  Problem  Input  -  Example:  ‘Time-line  information  on  phases  and  segments 
provided  by  Col  Bob  Cat  ("WPATB)  from  data  he  collected  and  pilot  interviews." 


e.  Design  Problem  Output  -  Ejcample:  ‘(KCl33.o£j‘ 


f.  Design  Problem  %  Complete  -  Ercample:  90% 

g.  Design  Problem  Notes  - 
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DA02.3 


a.  CAT  Software  Tool  -  MDTOOL 

b.  Inputs  -  from  subject  matter  experts  with  operational  experience  and 
documentation  from  procedure  DA02.2 

c.  Output  -  mission  objectives  text  file,  ■*.obj" 

d.  Design  Problem  Input  -  'EjcampCe:  same  as  ‘DJiOZ.ld 

e.  Design  Problem  Output  -  'E:(_ampU:  ‘KCUS.oBj 

f.  Design  Problem  %  Complete  -  'EjcampU;  90% 

g.  Design  Problem  Notes  - 


DA02.4 


a.  CAT  Softwore  Tool  -  MDTOOL 

b.  Inputs  -  from  subject  matter  experts  with  operational  experience 

c.  Output  -  mission  performance  text  file,  “.pfm" 

d.  Design  Problem  Input  - 


e.  Design  Problem  Output  - 


f.  Design  Problem  %  Complete  -  'EjcampU:  o% 

g.  Design  Problem  Notes  -  Tj(ampU:  10  Apr  91:  Cfiose  not  to  compUte  this  procedure  due 
to  its  inappGcoBUity 


DA02.5 


a.  CAT  Software  Tool  -  MDTOOL 

b.  Inputs  -  from  subject  matter  experts  with  operational  experience  and  output  of 
procedure  4 

c.  Output  -  documented  in  mission  performance  text  file,  ’Vpfm" 

d.  Design  Problem  Input  - 


e.  Design  Problem  Output  - 

f.  Design  Problem  %  Complete  -  ij^ampU:  0% 

g.  Design  Problem  Notes  -  'E^ampU:  su  procedure  E)!!102.4g 


DA02.6 


ndu  user  should  identify  aU  the  hugs  and  limitations  incurred  during  the  implementation  of  the 
ahove  proudures. 
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DA03.  PROCEDURES  FOR  CHARACTERIZING  THE  MISSION 


a.  CAT  Software  Tool  -  MDTOOL 

b.  Inputs  -  DMA,  DFADS,  DTED  databases 

c.  Outputs  -  specified  gaming  region 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA03.2 


a.  CAT  Software  Tool  -  MDTOOL 

b.  Inputs  -  from  mission  synopsis  specifications  and  subject  matter  expert 

c.  Outputs  -  target /threat  file  that  includes  target  parameters,  along  with  location  of 
targets  for  a  given  mission  scenario 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


a.  CAT  Software  Tool  -  MDTOOL 

b.  Inputs  -  from  mission  synopsis  specifications  and  subject  matter  expert 

c.  Outputs  -  target/threat  file  that  includes  threat  parameters,  along  with  location  of 
threats  for  a  given  mission  scenario 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 
p.  Design  Problem  Notes  - 
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DA03.4 


a.  CAT  Software  Tool  -  MDTOOL 

b.  Inputs  -  from  mission  synopsis  specifications  and  subject  matter  expert 

c.  Outputs  -  flight  path  file  that  irx:ludes:  airframe,  engine,  drspeed,  altitude,  and  g  limit 
parameters,  along  with  waypoint  locations  -  “•.wpf 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA03.S 


a.  CAT  Software  Tool  -  MDTOOL 

b.  Inputs  -  Mission  scenario  file  as  was  developed  by  procedure  DA03.1  through 
DA03.4  completion.  All  of  these  outputs  are  saved  to  one  scenario  file,  ".sen,"  that 
is  called  for  mission  execution  in  order  to  generate  the  mission  timeline. 

c.  Outputs  -  flight  data  recorder  file,  ‘•.fdr’ 
d  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA03.6 


a.  CAT  Software  Tool  -  MDTOOL 

b.  Inputs  -  From  the  Event  databases  available  in  the  current  release  of  MDTOOL,  and 
from  subject  matter  experts  to  clarify  what  realistic  events  would  occur  for  the  given 
mission  scenario. 

c.  Outputs  -  an  edited  flight  data  recorder  file,  ’Vfdr" 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA04.PROCEDURES  FOR  DEFINING  BASEUNE  CREW  STATION 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  -  From  weapon  system  description  document,  operational  experience, 
mission  and  system  requirements  database,  mission  scenario  database,  and/or 
crew  station  design  reports  and  drawings. 

c .  Outputs  -  documentation  of  existing  crew  station 

d.  Design  Problem  Inputs  - 


e .  Design  Problem  Outputs  - 


f. 

g- 

DA04.2 

a. 

b. 


c. 

d. 

e. 

f. 

g- 

DA04.3 

a. 

b. 


c. 

d. 

e. 

f. 

g- 


Design  Problem  %  Complete  - 


Design  Problem  Notes  - 


CAT  Software  Tool  -  N/A 

Inputs  -  from  weapon  system  description  document,  operational  experience, 

mission  and  system  requirements  database,  mission  scenario  database,  and/or 

crew  station  design  reports  and  drawings 

Outputs  -  documentation  of  avionics  performance  characteristics 

Design  Problem  Inputs  - 


Design  Problem  Outputs  - 


Design  Problem  %  Complete  - 
Design  Problem  Notes  - 


CAT  Software  Tool  -  N/A 

Inputs  -  from  weapon  system  description  document,  operational  experience, 
mission  and  system  requirements  database,  mission  scenario  database,  and/or 
crew  station  design  reports  and  drawings 

Outputs  -  documentation  of  vehicle  performance  characteristics  to  be  used  in 
MDTOOL  airframe  and  engine  parameter  specifications 
Design  Problem  Inputs  - 


Design  Problem  Outputs  - 
Design  Problem  %  Complete  - 
Demo  Notes  - 
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DA04.4 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  -  from  weapon  system  description  document,  operational  experience, 
mission  and  system  requirements  database,  mission  scenario  database,  ar>d/or 
crew  station  design  reports  and  drawings. 

c.  Outputs  -  documentation  of  weapons  performance  characteristics 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA04.5 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  -  From  avionics,  vehicle,  and  weapons  performance  characteristics 
specification  in  procedures  DA04.2  through  DA04.3,  determine  required  changes  in 
baseline  crew  station. 

c.  Outputs  -  Specification  and  documentation  of  required  changes  in  cockpit 
controls/displays,  operating  procedures,  and  crew  station  geometry. 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA04.6 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  -  From  procedure  DA04.5. 

c.  Outputs  -  Documentation  and  specification  of  control/display  suite  which  will  be 
input  into  the  cockpit  geometry  file  in  CIPLP,  to  output  a  ”*,ccc”  file. 

d.  Design  Problem  Inputs  - 


e .  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA04.7 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  -  from  procedure  DA04.5 

c.  Outputs  -  Documentation  of  baseline  crew  station  operating  procedures  for  the 
baseiine,  proposed  redesign,  or  for  the  entire  cockpit  control/dispiay  suite  for  new 
design  proposals. 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA04.8 


a.  CAT  Software  Tools  -  CIPLP 

b.  Inputs  -  from  procedure  DA04.6 

c.  Outputs  -  Documentation/specification  of  baseline  crew  station  geometry  and  the 
“.ccc"  cockpit  geometry,  cockpit  configuration  control  file. 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DAOS.PROCEDURES  FOR  GENERATING  CONTROL/DISPIAY  CATALOG 


DA05.1  Define/Uodate  Controls  and  Displav  (Indlcotort  Type  Usts 

a.  CAT  Software  Tools  -  CIPLP 

b.  Inputs  -  from  baseline  crew  station  definition  outputs,  and  avionics  design  team 

c.  Outputs  -  documentation  of  updated  control/indicator  lists,  edited  ’Vccc'  file 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA05.2  Assess  Complexity  and  Workload  for  Each  C/D  Type 

a.  CAT  Software  Tools  -  N/A 

b.  Inputs  -  from  subject  matter  experts 

c.  Outputs  -  documentation  of  updated  control/display  (indicator)  complexity  and 
workload  scores,  edited  ‘*.ccc'  file 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA05.3  Assess  Operator  Error  Likelihood  for  Each  C/D  Type 

a.  CAT  Software  Tools  -  N/A 

b.  Inputs  -  from  subject  matter  experts 

c.  Outputs  -  documentation  of  updated  control/indicator  error  likelihood,  edited 
”‘.ccc"  file 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA0S4 


a.  CAT  Software  Tools  -  N/A 

b.  Infxits  -  from  subject  matter  experts 

c.  Outputs  -documentation  of  updated  control/indicator  error  likelihood,  edited 
■•.ccc“  file 

d.  Design  Problem  Inputs  - 

e .  Design  Problem  Outputs  - 

f.  Design  Probiem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA06.PROCEDURES  FOR  PERFORMING  FUNCTION  ANALYSIS 


DA06.1  Identify  Functions  for  Each  Event 

a.  CAT  Software  Tool  -  NMT 

b.  Inputs  -  from  mission  function  database  arxl  subject  matter  experts 

c.  Outputs  -  specifications  for  the  creation  of  an  Event _Furx:tion  treenet, 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  • 

g.  Demo  Notes  - 


DA06.2  Prioritize  Functions  for  Each  Event 

a.  CAT  Software  Tool  -  NMT 

b.  Inputs  -  from  subject  matter  experts  and  procedure  DA06. 1 

c.  Outputs  '  specifications  for  editing  the  Event_Function  treenet,  **_EF.tnet‘ 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


“  EF.tner 


DA06.3  Insert  Functions  into  Timeline 


a.  CAT  Software  Tool  -  NMT 

b.  Inputs  -  from  procedure  DA06. 1 

c.  Outputs  -  Event_Function  treenet  structure  file, 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


••.EF.tnef 


DA06,4  Documentotion  of  the  Bugs  ond  Limitotions  of  NMT  Version:  (M  in  n/ersum  *) 
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DA07.PROCEDURES  FOR  AHACHING  TASKS  TO  PROCEDURES 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  -  “*.cccln‘  cockpit  geometry  file  and  subject  matter  expert 

c.  Outputs  -  specifications  for  a  function_procedure_task  treenet,  “Jpt.tnef 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA07.2 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  -  "Vccc"  cockpit  geometry  file  and  subject  matter  expert 

c.  Outputs  -  specifications  for  a  function_procedure_task  treenet,  “Jpt.tnef 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA07.3 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  -  ‘Vccc”  cockpit  geometry  file  and  subject  matter  expert 

c.  Outputs  -  specifications  for  a  function_procedure_task  treenet,  '•Jpt.tnef 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


57 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  -  ■•.cccin"  cockpit  geometry  file  and  subject  matter  expert. 

c.  Outputs  -  specification  for  task  sequence  for  a  given  cockpit  geometry  to  perform 
procedure 

d.  Design  Problem  Inputs  - 


e .  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA07.5 


a.  CAT  Software  Tool  -  NMT 

b.  Inputs  -  specifications  from  procedure  DA07. 1 

c.  Outputs  -  an  event_function_procedure_task  treenet  structure  stating  the  verb  to 
manipulate  the  specified  control  given  the  available  cockpit  geometry  “*.cccin‘ 
file,  “_EFPT.tnef 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA07.6 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  -  subject  matter  expert 

c.  Outputs  -  tasks  specified  in  sequence 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA07.7 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 

f.  Design  Probiem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA07.8 


EUminote  Task  Redundancies 


a.  CAT  Software  Tool  -  NMT 

b.  Inputs  -  subject  matter  expert  and/or  CSERIAC-CAT  Analyst 

c.  Outputs  -  edited  ‘•_EFPT.tnet‘ 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA07.9  Delete  Tasks  Which  Would  be  Shed  bv  the  Pilot 

a.  CAT  Software  Tool  -  NMT 

b.  Inputs  -  subject  matter  expert  and/or  CSERIAC-CAT  Analyst 

c.  Outputs  -  edited  “.EFPT.tnet’ 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


OA07.10  Documentation  of  the  Bugs  and  Limitations  of  NMT  Version:  (M  in  Version  # ) 
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DA08.PROCEDURES  FOR  PERFORMING  PROCEDURES  ANLAYSIS 


a.  CAT  Software  Tool  -  NMT 

b.  Inputs  -  from  Function.Procedure  database  and  subject  matter  expert 

c.  Outputs  -  specification  for  an  Event_Function_Procedure  treenet,  ■•_EFP.tnef 

d.  Design  Problem  Inputs  - 


e .  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Probiem  Notes  - 


DA08.2 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  -  from  subject  matter  expert 

c.  Outputs  -  procedure  criticality  specification 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA08.3 


a.  CAT  Software  Tool  -  NMT 

b.  Inputs  -  outputs  from  procedure  DA08.1  and  ’*_ef.tnet‘ 

c.  Outputs  -  '‘.etp-tnef 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA084 


a.  CAT  Software  Tool  -  NMT 

b.  Inputs  subject  matter  expert  and/or  CSERIAC-CAT  Analyst 

c.  Outputs  -  edited  "_efp.tnef 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA08.5 


Relocate  Procedures  Which  Would  be  Time-Shifted  bv  the  Pilot 


a.  CAT  Software  Tool  -  NMT 

b.  Inputs  -  subject  matter  expert  and/or  CSERIAC-CAT  Analyst 

c.  Outputs  -  edited  ■*_EFP.tnet' 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA08.6 


Documentation  of  the  Bugs  and  Limitotions  of  NMT  Version:  (fiU  in  ‘P'ersion  *) 


DA09.  PROCEDURES  FOR  PERFORMING  REACH  ANALYSIS 


DA09.1  Identify  Reference  Anthropometric  Database 

a.  CAT  Software  Tool  -  MCOS 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 
y.  Design  Probiein  Noies  - 


DA09.2  Establish  Criterion  Percentiles 

a.  CAT  Software  Tool  - 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA09.3  Calculate  Functional  Reoch  with  Harness  Locked 

a.  CAT  Software  Tool  -  OAR 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA094  Calculate  Maximum  Functional  Reach  with  Harness  Locked 

a.  CAT  Software  Tool  -  OAR 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Probiem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Prblem  Notes  - 
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DA09.5 


a.  CAT  Software  Tool  -  OAR 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 
e  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA09.6 


a.  CAT  Software  Tool  -  OAR 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Probiem  %  Compiete  - 

g.  Design  Problem  Notes  - 


DA09.7 


a.  CAT  Software  Too!  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Desin  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA09.9 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e .  Design  Probiem  Outputs  - 

I.  Design  Problem  %  Complete  - 
g.  Design  Problem  Notes  - 


DA10.PROCEDURES  FOR  PERFORMING  INTERNAL  VISION  ANALYSIS 


DA10.1  Define  SvmbQl/Character  Size  and  Contrast  Requirements 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e .  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA10.2  Define  Phosphor  Color  and  Persistence  Requirements 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA10.3  Define  Imoge  Linearity.  Jitter  and  Drift  Requirements 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA10.4  Define  Image  Resolution  and  Accuracy  Requirements 

a.  CAT  Software  Tool  -  DLA 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA10.5 


Hafine  Brightness.  Uniformity  ond  Adjustment  Requirements 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DAIO.6  nafine  Nioht  Vision  Device  Compotibilitv  ReauifenoentS 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DAI 0.7  Assess  Vision  Obstructions 

a.  CAT  Software  Tool  -  E-VISION 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DAIO.8  nafir^e  Brightness  and  Brightness  Range  Requirements 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA10.9 


Define  Cockpit  Uahtina  Color  Requirements 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e .  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA10.10  Define  Cockpit  Labels  and  Legends  Size  and  Color  Requirements 

a.  CAT  Software  Tool  -  DLA 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DAlO.ll  Define  Cockpit  Signals  Size.  Color  and  Brightness  Requirements 

a.  CAT  Software  Tool  -  DLA 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA10.12  Document  Internal  Vision  Analyses 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA10.13  Documentation  of  Bugs  and  Limitations  of  DLA  and  E-V!son  Version 


(fiCCin  'Iverson  #) 
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DAI  1. PROCEDURES  FOR  PERFORMING  EXTERNAL  VISION  ANALYSIS 


DAll.l  Produce  Total  Vision  Envelope  Plots 

a .  CAT  Software  Tool  -  E VISION 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DAI  1 .2  Produce  Landing  Approach  Vision  Plots 


a.  CAT  Software  Tool  -  EVISION 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  * 


DAI  1.3  Conduct  Tronsr^arencv  Analyses 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DAIM  Assess  Eve  Protection  ReauiremePTs 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA1 1.5 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete 

g.  Design  Problem  Notes  - 


DA1 1.6 

a. 

b. 

c. 

d. 


CAT  Software  Tool  -  N/A 
Inputs  - 
Outputs  - 

Design  Problem  Inputs  - 


DA1 1.7 


e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete 

g.  Design  Problem  Notes  - 


DA12.PROCEDURES  FOR  PERFORMING  WORKLOAD  ANALYSIS 


a.  CAT  Software  Tool  -  CASS 

b.  Inputs  -  from  CASS  software  tool  specifications,  subject  matter  experts,  and 
possibly  specifications  made  in  the  MDTOOL  '.ptm  file 

c.  Outputs  -  documentation  of  pre-established  workload  level  criteria 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA12.2 


a.  CAT  Software  Tool  -  MPE 

b.  Inputs  -  “*.ccc“  cockpit  geometry  file  and  “‘.nmt.msain"  file  created  using  NMT 

c.  Outputs  -“‘.mpe. report"  for  documentation  of  procedure  execution  times, 
“•_mpe.mtabin"  input  file  for  MTA,  ‘*_mpe.farin2‘  input  file  for  FAR 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA12.3 


a.  CAT  Software  Tool  -  MPE  and  "*_MPE. report"  file  for  easiest  look  up 

b.  Inputs  -  from  the  "Procedure  Initiation/Execution  Time  Summary"  section  of 
'•_MPE.report"  output  file  of  procedure  DAI 2.2 

c.  Outputs  -  determination  of  which  procedures  will  cause  hang-ups  because  they 
take  too  long,  given  the  time  actually  available 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA1Z4 


o.  CAT  Software  Tool  -  MPE 

b.  Inputs  -  '.MPE. report  file 

c.  Outputs  -  documentation  of  suggested  targets  for  automation  or  coupling  of 
activities  or  information 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA12.S 


a.  CAT  Software  Tool  -  MPE 

b.  Inputs  -  "‘.mpe.reporf  results  in  procedure  DA12.3 

c.  Outputs  -  documentation  of  procedures  with  time  availability  problems 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Probiem  %  Complete  - 

g.  Design  Problem  Notes  - 


a.  CAT  Software  Tool  -  MPE 

b.  Inputs  -  "Procedure  Task  Workload  Report"  from  "'.MPE-Report"  file 

c.  Outputs  -  documentation  of  the  complexity  of  each  of  the  tasks  performed  and  for 
the  complexity  of  the  total  procedure 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA12.7 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA12.8 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  -  output  from  Procedure  DA  12.6c 

c.  Outputs  -  documentation  of  the  procedures  with  task  complexity  problems 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA12.9 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  -  from  procedure  DA  12.8c 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e .  Desig  n  Pro  ble  m  O  utputs  - 


f.  Design  Probiem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA12.10 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  -  outputs  of  Procedures  DAI 2.5c,  DA  12.8c,  DA  12.9c,  DA12.1  Ic 

c.  Outputs  -  documentation  of  problem  procedures  and  tasks  for  use  in  design 
recommendations,  information  analysis,  and/or  trade-off  studies 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA12.11 


a.  CAT  Software  Tool  -  MTA 

b.  Inputs  -  'Problem  Procedure  Report'  from  ".MTA.Report'  file 

c.  Outputs  -  documentation  of  problem  procedures  based  on  channel  workload 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA12.12  Documentation  of  the  Bugs  and  Umitations  of  CASS  Version:  (M  in  Version 


a.  PET  -  is  a  quick  way  to  get  procedure  durations.  PET  also  calculates  workload 
characteristics  for  isoiated  procedures. 

b. MSA  -  provides  the  user  with  a  listir^g  of  the  time-line,  and  frequency  of  use 
statistics  for  devices  (controls  and  displays)  to  give  the  analyst  a  heads  up  for 
possible  control/display  problem  areas. 

c. MPE  -  calculates  workload  statistics  for  each  procedure  in  the  time-line, 
performs  link  anaiysis,  specifies  task  arwj  procedure  compiexity,  and  provides 
procedure  execution  times. 

d. MTA  -  sums  the  MPE  generated  workload  data  by  time  interval,  identifies 
workload,  peaks  and  contributions,  reports  overall  workload  statistics,  and 
prepares  workload  plots. 

e. MTP  -  provides  an  alternate  workload  measure:  the  probability  of  an  activity 
in  a  channel  each  second  of  the  time-line. 

f. PLTGGP  -  generates  2D  or  3D  workload  plots.  To  run  this  program,  DI3000  must 
be  installed  on  the  MicroVAX  II,  and  the  GPX  terminal  print  logicals  must  be  set 
appropriately. 

g. FAR  -  provides  workload  reports  focusing  on  functions  rather  than 
procedures. 

h. C-SAINT  -  generates  a  summary  report  of  the  amount  of  time  the  pilot  is 
rushed,  the  amount  of  time  the  pilot  is  busy,  the  number  of  procedures  the  pilot 
is  behind,  and  the  number  of  procedures  the  pilot  skipped. 
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e .  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA13^ 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA13.6 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outpijts  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA13.7 


a.  CAT  Software  Tool  -  lATOOL 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DAI  3.8 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e .  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA13.9 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA13.10 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Output? 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA13.11 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e .  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA13.12 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA13.13 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete 

g.  Design  Problem  Notes  - 


DA13.14 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Probiarri  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete 

g.  Design  Problem  Notes  - 


DA13.15 


ting  an< 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete 

g.  Design  Problem  Notes  - 


DA13.16 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete 

g.  Design  Problem  Notes  - 


77 


DA13.17 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problen.  Inputs  - 

e .  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA13.18 


osentQtion 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA13.19 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA15.  PROCEDURES  FOR  PERFORMING  CRITICAL  TASK  ANALYSIS 


DA15.1 


DA15.2 


i 

j 

1 


0A1S.3 


DAI  5.4 


Identify  Critical  Tasks 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Probiem  Notes  - 


Define  Procedure  for  Accomplishing  Task 

a.  CAT  Software  Tooi  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


Identify  Optional  or  Attemative  Procedures 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Probiem  %  Complete  ■ 

g.  Design  Problem  Notes  - 


Define  Pilot  Performance  Capability  Umits 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DAI 5.5  Define  System  Performance  Capability  LifnitS 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e .  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA15.6  Identify  Actions  Required  bv  Critical  Tasks 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA  15.7  Identify  Task  Initiation  Information. 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DAI 5.8  Identify  Task  Performance  Feedback  InfPrmqtlQQ 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DAI  5.9 


Identify  Operator  Information  Reauifements 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA15.10  Identify  Task  Completion  Criteria  and  Tolerances 

a.  CAT  Software  Tool  -  N/A 

b.  inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA15.11  Identify  Potential  Performance  Errors 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA15.12  Identify  Potential  Hazards 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA15.13 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA17.PROCEOURES  FOR  PERFORMING  FUNCTION  ALLOCATION  ANALYSIS 


DAI  7.1  Identify  Possible  Mission  Performance  Problems 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DAI  7.2  lD_and  Prioritize  Activities  Within  the  Segments 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA  1 7.3  Identify  Problem  Drivers 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DAI  74  Automate  Functions  or  Parts  of  Functions 

a.  CAT  Software  Tool  -  NMT 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e .  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 
g  Design  Problem  Notes  - 


DAI  7.5 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DAI  7.6 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DAI  7.7 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs* 

d.  Design  Problem  Inputs  - 


e .  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  * 


DAI  7.8 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DAI  7.9 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA17.10 


a.  CAT  Software  Tool  -  CIPLP 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA17.11 


a.  CAT  Software  Tool  -  CIPLP 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA17.12 


a.  CAT  Software  Too!  -  NMT 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e .  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DAI  7. 13 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e .  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA18.1 


a.  CAT  Software  Tool  -  SUMMET 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DAI  8.2 


a.  CAT  Software  Tool  -  SUMMET 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


OA18.3 


a.  CAT  Software  Tool  -  SUMMET 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e.  Design  Problem  Outputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA184 


a.  CAT  Software  Tool  -  SUMMET 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


allcx:ation  candidates 


DA18.5 


a.  CAT  Software  Tool  -  SUMMET 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA18.6 


a.  CAT  Software  Tool  -  SUMMET 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 


e .  Desig  n  Pro  ble  m  O  utputs  - 


f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA19.PROCEDURES  FOR  DEFINING  CONTROL  AND  DISFIAY  CONCEPT 


DAI  9.1  Identify  Controls  and  Displays  to  be  Eliminated 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Probiem  Notes  - 


DAI 9.2  identify  New  Controis/Disploys  to  be  Created 

a.  CAT  Software  Tooi  -  N/A 

b.  Inputs  - 

c.  Outputs - 


d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete 

g.  Design  Probiem  Notes  - 


DA  19.3  Describe  Display  Format  Info  Elements 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Probiem  Notes  - 


DAI 9.4  Describe  Display  Dynamics 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete 

g.  Design  Problem  Notes  - 
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DA19.5 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DAI  9.6 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Probiem  inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA19.7 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c .  Outputs  - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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da20.pikx:eoures  for  formulating  operational  guidelines 


DA20.1 

a. 

b. 

c. 

d. 

e. 

f. 

g 

DA20.2 

a. 

b. 

c. 

d. 

e. 

f. 

g 

OA20.3 

a. 

b. 

c. 

d. 

e. 

f. 

g^ 

DA20^ 

a. 

b. 

c. 

d. 

G. 

f. 

g^ 


identify  Existing  Pfocedures  to  be  ModifiGd 

CAT  Software  Tool  -  N/A 
Inputs  - 
Outputs  - 

Design  Problem  Inputs  - 

Design  Problem  Outputs  - 

Design  Problem  %  Complete  - 
Design  Problem  Notes  - 


Describe  Modifications  to  Existing  Procedures 

CAT  Software  Tool  -  N/A 
Inputs  - 
Outputs  - 

Design  Problem  Inputs  - 

Design  Problem  Outputs  - 

Design  Problem  %  Complete  - 
Design  Problem  Notes  - 


ideotify^New  Procedures  to  be  Creoted 

CAT  Software  Tool  -  N/A 
Inputs  - 
Outputs  - 

Design  Problem  Inputs  - 

Design  Problem  Outputs  - 

Design  Problem  %  Complete  - 
Design  Problem  Notes  - 


Describe  New  Procedures 

CAT  Software  Tool  -  N/A 
Inputs  - 
Outputs  - 

Design  Problem  Inputs  - 

Design  Problem  Outputs  - 

Design  Problem  %  Complete  - 
Design  Problem  Notes  - 
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a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA21. PROCEDURES  FOR  ESTABLISHING  EQUIPMENT  REQUIREMENTS 


DA21.1  Identify  Existing  Equipment  to  be  Modified 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Probiem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA21.2  Describe  Modifications  to  Existing  Equipment 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e .  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA21.3  Identify  New  Equipment  to  be  Acquired 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 


DA214  Describe  New  Equipment 

a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e.  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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DA21.5 


a.  CAT  Software  Tool  -  N/A 

b.  Inputs  - 

c.  Outputs - 

d.  Design  Problem  Inputs  - 

e .  Design  Problem  Outputs  - 

f.  Design  Problem  %  Complete  - 

g.  Design  Problem  Notes  - 
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